| access to the super version of an operation [message #46871] |
Sun, 16 December 2007 07:44  |
 Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
I forwarded Christian Damus's reply to my question about this topic
to the chairman of the OCL 2.1 RTF task force, Mariano Belaunde.
The following is his personal opinion, and they will decide on the
issues rised by Christian until the 2.1 releas in March or June:
Mariano Belaunde wrote:
Hi Philipp,
In the actual OCL spec there is a confusion between two different things:
- casting (oclIsType)
- forcing the access to an overriden operation in a superclass.
There is already an issue on this problem in the issue database.
Normally this will be solved in next OCL 2.1 release (in March
or June 2008).
For me the expected behavior when using casting should be to call
in any case the operation that is more close to the actual type.
(Just as in Java). For forcing the invocation of the overrriden
operation we need a different syntax.
In the OCL implementation included in SmartQVT we have made this
distinction.
Kind Regards,
Marianio
-----Message d'origine-----
De : Philipp W. Kutter [mailto:kutter@montages.com]
Envoyé : mercredi 12 décembre 2007 21:48
À : BELAUNDE Mariano RD-MAPS-LAN
Objet : ocl question regarding casting
Der Mariano.
We met at the Brussels OMG meeting.
We now started to use OCL heavily and we develop a bunch of EMF
templates to define (and override) features, operations, choices, e.t.c.
If your group is interested, we would be ready to share it.
I have the following question, which actually is an answer of Christian
Damus to my question on the eclipsee ocl group:
>> Philipp Kutter asked on the MDT OCL newsgroup:
>> TOPIC: Access to the super version of an operation
>>
>> We use OCL to define the "body" of operations, as
>> in Christian Damus's Example.
>>
>> If such an operation overrides one from the super class,
>> how can I call in such an operation the super-version
>> of the same operation?
>
>
> Christian Damus answered:
>
> If your OCL expression has a variable b of type B which
> specializes A, and B redefines an operation foo() and a
> property x from A, then you can invoke these features of A
> by casting:
>
> b.oclAsType(A).foo()
>
> b.oclAsType(A).x
>
> However, MDT OCL does not support this usage. Indeed, as it
> is specified by OMG, it would be a little difficult to
> implement and has semantics inconsistent with variable
> initialization, anyway. Consider that, using the above
> example, if the following indicates that we want to access
> A's definition of foo()
>
> b.oclAsType(A).foo()
>
> then what does the following mean?
>
> let bAsA : A = b.oclAsType(A) in
> bAsA.foo()
>
> Should this invoke A::foo() or B::foo()? I would expect
> the latter, for consistency with the following in which
> A additionally has a self-association A::relatedAs:
>
> a.relatedAs->collect(rel : A | rel.foo())
>
> In this case, one clearly expects that for any Bs in
> the collection of relatedAs, we would get B::foo() despite
> the fact that the rel variable's static type is A.
What is your OCL implementation ans what is the standard doing here?
Is usage of oclAsType to cast from a sub-type to a super-type allowed at
all?
Is Christian's remark, that the OMG specification has semantic
inconsistence true?
Thanks a lot in advance,
Regards, as well to Greg Dupe,
Philipp
|
|
|
| Re: access to the super version of an operation [message #46901 is a reply to message #46871] |
Sun, 16 December 2007 19:08  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
Yes, I think I saw some problems with oclAsType() in the OCL 2.0 RTF's
issues list.
I could imagine a syntax like:
b.A::foo()
to invoke the A::foo() definition of the operation explicitly instead of
B's redefinition. This would require, I expect, some enhancement to the
FeatureCallExp metaclass to indicate the static binding of the feature
(operation or property) call.
Cheers,
Christian
|
|
|
Powered by
FUDForum. Page generated in 0.02763 seconds
] 
Search
Help
Register
Login
Home
