Closed istvanrath closed 12 years ago
I have verified that this works well with the school example so I'm closing this issue.
Actually this new type inference feature broke 5 testcases in the UnusedVariableValidationTest. I don't know whether Zoli will have the time to fix them before the release, or I should look into it.
2012/9/26 Istvan Rath notifications@github.com
I have verified that this works well with the school example so I'm closing this issue.
— Reply to this email directly or view it on GitHubhttps://github.com/ujhelyiz/EMF-IncQuery/issues/304#issuecomment-8891760.
Unfortunately, a related problem is still present:
pattern teachesMoreClasses(T1:Teacher, T2:Teacher) {
N == count find classesOfTeacher(T1,_SC1);
M == count find classesOfTeacher(T2,_SC2);
check(N > M);
}
Here, the Teacher type constraint for T1 is necessary, but I think it could be inferred from the count find call and shouldn't be necessary.
Removing the Teacher type constraint is not that simple (the semantics of the language are designed that the parameter type is equivalent of writing a similar EClass constraint - in this case Teacher(T1)).
In spring, when working with the reference counter validation, if I remember correctly, @bergmanngabor said that a type constraint is required for the network to calculate the possible set of teachers, so the reference counter validator would disallow this omission. I might be wrong, as I see no reason now for this limitation, but the validator is implemented that way.
For this release, I suggest not implementing this additional type inference feature, and validate this outside the 0.6 timeframe.
@istvanrath I don't have time to write up a detailed analysis here, but the short answer is that I believe you are wrong. We should discuss this later in person to see if you can convince me.
@ujhelyiz just to clarify, the reason for the validation rule is not a Rete limitation, but a semantics problem independent from the engine implementation.
@bergmanngabor ok. closing.
Take the school example for instance:
Here, the inferred Java type of N and M should be Integer, but now it is Object.