[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] retyping through oclAsType; clarifications
|
Hi Ed,
comments inlined below.
Regards,
Laurent
Ed Willink a écrit :
Hi Laurent,
What are your -----8>----- characters?
Simply tries to separate the parts I pasted from the specification ;).
1) I agree completely with your first email.
Yes. There is a direct contradiction. null/invalid.
The ambiguity arises from one clear resolution, Issue 7341; bad
casting is invalid.
Issue 10437 provides the contradictory null in 11.2.5, but only in
undiscussed revised text.
Can the ballotted contradictions be resolved without a further/revised
ballot? OCL 2.1
seems to be more seriously ambiguous than OCL 2.0.
I haven't taken a look at the issues that might be related to the
problem. Can I let you take care of raising the needed issues for this?
2) You seem to have got confused between subtype and supertype in the
second email
Indeed. I guess I have been staring at the specification too long :p.
Treat Annex A with considerable caution and always check with 03-01-07
which is the original FrameMaker document
without accidental transcription errors. The Annex has minimal
treatment of invalid/null distinction. I raised
http://www.omg.org/issues/ocl2-rtf#Issue14197 at the weekend to
provide resolution.
Regardless of the resolution, OclVoid is a subtype of nearly all
types. This does not mean the cast to OclVoid is valid.
OclVoid has at most two values null and invalid, neither of which is
"3", so the cast to OclVoid is not valid and so
the result is invalid. More easy to understand is Integer is a subtype
of Real, so 3.14 is a Real but it cannot be cast
to Integer. 3.0 is probably parsed to a Real and so is also not an
Integer. This makes it important to parse 3 as an
UnlimitedNatural and keep it as such.
http://www.omg.org/issues/ocl2-rtf#Issue14196 defines UnlimitedNatural
and as with MOF's integer etc re-uses XML schema definitions. This
tells us that -0, +0 are both valid UnlimitedNatural
non-canonical forms of the canonical form 0.
Parse 3 as an UnlimitedNatural? I know the specification is unclear as
regard the definition of the UnlimitedNatural, I thought you raised an
issue to make it conform to Integer with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=261008 . Yet this I do not
understand. 3 is clearly an Integer and should be parsed as such. I'd
have seen the unlimited natural as only a special value which would be
"*" and which wouldn't have an actual equivalent in the Integer realm
(much like Java's Double.POSITIVE_INFINITY). With your proposed
resolution, what would happen with operations such as "*.-()" or "* =
-1" ? The current implementation returns respectively "1" and "true"
which I understand as totally wrong. Can you elaborate on your proposed
resolution and its impacts (maybe directly on the bug above so as to
avoid polluting the mailing list :))?
I agree with the expected results. We just need to get the text to say
so without ambiguity. Looks like I'd better
do yet another Issue response.
I'll leave you raise the issue then, thanks :).
Regards
Ed Willink
Laurent Goubet wrote:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
