| Hi, Adolfo,
I agree that UnlimitedNatural should not be a subtype of Real, but that might be an incompatible API change. I'm not gravely concerned about it because arithmetic on the unlimited value is uninteresting, but it is possible that models out there already have UN-typed properties on which Real operations are invoked.
Is it something that could wait until Release 2.0?
cW
On 12-Jan-09, at 6:43 AM, Adolfo Sánchez-Barbudo Herrera wrote: Hi Christian, Some in-lined comments:
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. Therefore, there is no reason for considering that UnlimitedNatural as a subtype of Real, which will need to be fixed.
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. My question had another concerns. I was thinking about the fact that UnlimitedNatural type has the same operations Integer has. However, I was confused, that operations come from considering UnlimitedType as a Real subtype.
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. So, as a conclusion I think that a possible patch to solve the related issue would enclose the following matters: - Revising commonSuperType, so that OclAny is considered a common super type in every case, excepting the cases we deal with collection types. - Revising getRelationShip so that UnlimitedNatural must not be considered a Real's subtype. - Revising test cases. Some of them have incorrect considerations about type conformance.
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. I understand, and I agree with you. I hadn't thought about the use of the symbol * in OCL expressions (I'm usually so immerse in the low-level parsing world), and it doesn't make sense a query which checks if a company have infinite employers >.< Thank you very much for the response. 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
|
