Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] retyping through oclAsType; clarifications

And I forgot part of the question ...

We're told that "If the actual type of the object, at evaluation time, is not a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.". Yet A.2.6 tells us "OclVoid is the subtype of all other types." which would mean C is not invalid ... but what would be the result?

Laurent Goubet a écrit :
Hi all,

I need some clarifications about the actual definition of the "oclAsType" operation. I'll refer to some parts of the specification here and there; I'm refering to the 2.1 draft for this.

here are the four examples I'll base my ramblings on :

A- 3.oclAsType(Integer)
B- 3.oclAsType(Real)
C- 3.oclAsType(OclVoid)
D- 3.oclAsType(OclInvalid)

And the actual question : what are the expected results of each of these? I would say
A- integer "3"
B- integer "3"
C- invalid
D- invalid

Why I am confused about these?
7.4.6 tells us :
----------8<----------
object.oclAsType(Type2) --- changes the static type of the expression to Type2 An object can only be re-typed to a type to which it conforms. If the actual type of the object, at evaluation time, is not a subtype of the type to which it is re-typed, then the result of oclAsType is invalid. Casting provides visibility, at parse time, of features not defined in the context of an expression's static type. It does not coerce objects to instances of another type, nor can it provide access to hidden or overridden features of a type. For this, the feature call is qualified by the name of the type (a path name, if necessary) whose definition of the feature is to be
accessed.
---------->8----------
Which confirms the "expected results" I gave above. Yet
7.5.9 lists :
----------8<----------
oclAsType (t : OclTypeClassifier) : instance of OclType
---------->8----------
so the result of B should be the "double" 3.0 and not the "integer" 3.
11.2.5 seems to confirm this with the post condition of oclAsType :
----------8<----------
post: (result = self) and result.oclIsTypeOf( t )
---------->8----------
Except if "oclIsTypeOf" checks the static type of its source instead of its actual type.

I believe that both 7.5.9 and 11.2.5 should be revisited to take into account the rules of 7.4.6 that were updated with OCL 2.1. Furthermore, 7.4.6 tells us that "If the actual type of the object, at evaluation time, is not a subtype of the type to which it is re-typed, then the result of oclAsType is invalid." whereas 11.2.5 says "if the actual type of self at evaluation time does not conform to t, then the oclAsType operation evaluates to null." which makes unclear the results of both C and D above.

What do you think about these?

Laurent
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev




Back to the top