| [mdt-ocl.dev] Working on the incorrect commonSuperType |
|
Hi Christian, I would like to comment with you some ideas related to a bug that has been recently issued by Radek: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260403 I think that I have reached a first approach to solve the problem. However I would like to comment about a special test case in which I have detected some problems. The expressions to consider are the following "2 + *" and "* + 2" If I don't change the the commonSuperType implementation I have the following errors for both examples: Got expected exception: Type mismatch. No common supertype: (UnlimitedNatural), (Integer) Got expected exception: Type mismatch. No common supertype: (Integer), (UnlimitedNatural) This is incorrect, since they obviously have a common supertype : OclAny. Besides, IMO that there is an incorrect consideration in getRelationship method in which Real is considered as strict subtype of both Integer and UnlimitedNatural (Integer). I think that the specification just says that Integer conforms to Real, anything else related to UnlimitedNatural (BTW a poor description in the spec about it, even in a place mention something about a UnlimitedIntegerType metatype). Besides it seems that UnlimitedNatural (Integer) is considered as an Integer in the OCL Standard Library with all Integer's operations, is this correct ?¿?. Its not clear for me, at least reading the spec. Beside, which kind of sense make adding something to the unlimited value (*) ? In any case, * must be the result Fixing commonSuperType and getRelationship methods would produce the following error (which I would really expect) for the example "2 + *" Got expected exception: Cannot find operation (+(UnlimitedNatural)) for the type (Integer). However because of the design of the stdlib in which UnlimitedNatural primitive type have the integer operations (+(Real) ) I can't do anything whith the other example "* + 2" at parsing time. At least, the implementation evaluates those expressions to invalid. ------------- Another idea is considering the type conformance between Integer and UnlimitedNaturals, so that Integer conforms to the UnlimitedNatural type (which is always valued as *). Anyway, I think that OCL specification should better clarify the rules of type conformance (if any) between this primitive types. So that we don't have to make interpretations about which are valid (parsed/evaluated) expressions and which are not (and why they are not valid). Cheers, Adolfo. --
|
