| Hi, Adolfo,
Sounds like you've put a good deal of effort into this!
See some comments in-line, below.
Cheers,
Christian
On 9-Jan-09, at 2:04 PM, Adolfo Sánchez-Barbudo Herrera wrote: 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.
Great! Thanks for taking up this task.
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.
Right, assuming (as we currently are) the assertion of bug 260403 that OclAny ensures that all pairs of types have a common supertype. It's nice to have a closed type system.
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 you mean, rather, that it is considered a strict *supertype* of Integer and UnlimitedNatural.
I think that the specification just says that Integer conforms to Real,
Correct.
anything else related to UnlimitedNatural (BTW a poor description in the spec about it, even in a place mention something about a UnlimitedIntegerType metatype).
Right. UnlimitedNatural is poorly defined. Mathematically, the naturals are a subset of the integers, but UML adds an explicit infinity (which is mathematically bogus, btw) that, by definition, falls outside of the range of the Integer type. So, UnlimitedNatural cannot be a subtype of Integer, nor can Integer be a subtype of UnlimitedNatural because of the negative values.
Besides it seems that UnlimitedNatural (Integer) is considered as an Integer in the OCL Standard Library with all Integer's operations, is this correct ?¿?.
Well, we had to map UnlimitedNatural to a Java type, and chose int/Integer to align with MDT UML2 and to avoid the performance cost of BigInteger.
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
Heh heh ... a good point. Hence the mathematical bogosity of the * value. Actually, * only makes sense as a value in multiplicity specifications. It can hardly ever be useful in OCL expressions because it UnlimitedNaturals only occur in metamodels (upper bounds of MultiplicityElements). They are never used in models.
Note, also, that the *only* UnlimitedNatural literal value that OCL can express in the * value, because all numeric values look like Integers. There is no defined relationship between UnlimitedNatural and Integer types and no coercion operations, to convert between these types.
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.
I wouldn't worry about that: it can hardly be an interesting case. No useful OCL expressions will run into this :-)
-------------
Another idea is considering the type conformance between Integer and UnlimitedNaturals, so that Integer conforms to the UnlimitedNatural type (which is always valued as *).
As I mentioned already, we cannot do this. The negative integers don't fit.
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).
Absolutely! I think the UnlimitedNatural type should be eliminated. There is no need for a * value in multiplicities: it is a nice visual representation in diagrams, but the MultiplicityElement can just as well have an " / isUnlimited : Boolean" attribute as well as an optional "upperBound : Integer" attribute (the derived isUnlimited attribute being determined by the absence of the upper bound). The UnlimitedNatural is more trouble than it's worth; an abomination.
Cheers, Adolfo. -- <logo.jpg>
| Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
-- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV
|
