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.
--

|
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 |
|