Home » Modeling » OCL » Visibility of interface operations to implementing classifiers
|
| Re: Visibility of interface operations to implementing classifiers [message #62643 is a reply to message #62619] |
Wed, 08 October 2008 20:39   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Linda,
Does the class T happen to define an operation like this?
compareTo(T) : Integer
Or, does T correspond to an EClass whose instanceClass is of some
java.lang.Comparable type? In either case, the 1.1.x release would
infer the <(T):Boolean operation even if it wasn't defined. This is a
Java-ism that isn't applicable to OCL, so the 1.2 release corected that
by no longer making this inference. However, the 1.2 API does allow you
to restore the 1.1 behaviour by setting the
ParserOptions.USE_COMPARE_TO_OPERATION option. Try using the
ParserOption.setOption(...) method to set this option on your
environment before you parse (the root environment of your
org.eclipse.ocl.OCL façade is a good choice).
In any case, the Interface thing is a red herring. Classes don't
inherit features from the interfaces that they implement, so OCL won't
see a < operation in T unless T defines one or inherits it from another
class. Our UML binding has always respected that.
HTH,
Christian
Linda Damus wrote:
> Should interface operations be visible to their implementing classifiers
> in OCL?
>
> I'm using MDT OCL 1.2.0. I have a UML model containing Interface I with
> a query operation <(param:I):Boolean, and a Class T that realizes I (but
> does not own a corresponding query operation <(param:I):Boolean).
> Another Class C has two attributes a1:T and a2:T. Using the OCL
> Interpreter Example (evaluating for UML at the M1 modeling level), I
> find that the following expression:
>
> self.a1 < self.a2
>
> fails to parse with the error: Cannot find operation (<(T)) for the type
> (T)
>
> Is this the correct behaviour? I've verified that this same expression
> parses without errors in MDT OCL 1.1.2.
>
> Thanks,
> Linda
|
|
|
| Re: Visibility of interface operations to implementing classifiers [message #62668 is a reply to message #62643] |
Thu, 09 October 2008 13:57 |
 Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------060200070408020004030700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
T does not have any operations, actually. Nor does it correspond to an
EClass whose instanceClass is a java.lang.Comparable. I'm not sure why
the 1.1.2 release was able to see the < operation from the interface.
Given that classes don't inherit features from interfaces, is it because
of a defect that has subsequently been fixed in the 1.2.0 release?
I've attached a project that contains my .uml model, in case it helps to
clarify what I'm doing.
Thanks,
Linda
Christian W. Damus wrote:
> Hi, Linda,
>
> Does the class T happen to define an operation like this?
>
> compareTo(T) : Integer
>
> Or, does T correspond to an EClass whose instanceClass is of some
> java.lang.Comparable type? In either case, the 1.1.x release would
> infer the <(T):Boolean operation even if it wasn't defined. This is a
> Java-ism that isn't applicable to OCL, so the 1.2 release corected that
> by no longer making this inference. However, the 1.2 API does allow you
> to restore the 1.1 behaviour by setting the
> ParserOptions.USE_COMPARE_TO_OPERATION option. Try using the
> ParserOption.setOption(...) method to set this option on your
> environment before you parse (the root environment of your
> org.eclipse.ocl.OCL fa
|
|
|
| Re: Visibility of interface operations to implementing classifiers [message #62740 is a reply to message #62668] |
Thu, 09 October 2008 17:59 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Linda,
Thanks for the attachment. I debugged it and have surprised myself.
The OCL 1.1 release has a bug, which evidently was fixed in 1.2 though I
don't remember it. In 1.1, the OclAny type from the OCL Standard
Library has all of the comparison operations <, <=, >, >=. This is at
odds with the OCL 2.0 specification, which defines only = and <> in the
OclAny context.
So, in 1.1.x, *all* types in the user model to have the comparison
operations imposed upon them. Happily, the 1.2 release fixes that :-)
Cheers,
Christian
Linda Damus wrote:
> T does not have any operations, actually. Nor does it correspond to an
> EClass whose instanceClass is a java.lang.Comparable. I'm not sure why
> the 1.1.2 release was able to see the < operation from the interface.
> Given that classes don't inherit features from interfaces, is it because
> of a defect that has subsequently been fixed in the 1.2.0 release?
>
> I've attached a project that contains my .uml model, in case it helps to
> clarify what I'm doing.
>
> Thanks,
> Linda
>
>
> Christian W. Damus wrote:
>> Hi, Linda,
>>
>> Does the class T happen to define an operation like this?
>>
>> compareTo(T) : Integer
>>
>> Or, does T correspond to an EClass whose instanceClass is of some
>> java.lang.Comparable type? In either case, the 1.1.x release would
>> infer the <(T):Boolean operation even if it wasn't defined. This is a
>> Java-ism that isn't applicable to OCL, so the 1.2 release corected
>> that by no longer making this inference. However, the 1.2 API does
>> allow you to restore the 1.1 behaviour by setting the
>> ParserOptions.USE_COMPARE_TO_OPERATION option. Try using the
>> ParserOption.setOption(...) method to set this option on your
>> environment before you parse (the root environment of your
>> org.eclipse.ocl.OCL façade is a good choice).
>>
>> In any case, the Interface thing is a red herring. Classes don't
>> inherit features from the interfaces that they implement, so OCL won't
>> see a < operation in T unless T defines one or inherits it from
>> another class. Our UML binding has always respected that.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Linda Damus wrote:
>>> Should interface operations be visible to their implementing
>>> classifiers in OCL?
>>>
>>> I'm using MDT OCL 1.2.0. I have a UML model containing Interface I
>>> with a query operation <(param:I):Boolean, and a Class T that
>>> realizes I (but does not own a corresponding query operation
>>> <(param:I):Boolean). Another Class C has two attributes a1:T and
>>> a2:T. Using the OCL Interpreter Example (evaluating for UML at the
>>> M1 modeling level), I find that the following expression:
>>>
>>> self.a1 < self.a2
>>>
>>> fails to parse with the error: Cannot find operation (<(T)) for the
>>> type (T)
>>>
>>> Is this the correct behaviour? I've verified that this same
>>> expression parses without errors in MDT OCL 1.1.2.
>>>
>>> Thanks,
>>> Linda
>
|
|
|
| Re: Visibility of interface operations to implementing classifiers [message #63113 is a reply to message #62740] |
Tue, 14 October 2008 13:31 |
Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
In MDT OCL 1.2.0, I see that implementation of
OCLStandardLibraryUtil#createAnyTypeOperations still seems to return <,
>, <= and >=. Is that correct?
Thanks,
Linda
Christian W. Damus wrote:
> Hi, Linda,
>
> Thanks for the attachment. I debugged it and have surprised myself.
>
> The OCL 1.1 release has a bug, which evidently was fixed in 1.2 though I
> don't remember it. In 1.1, the OclAny type from the OCL Standard
> Library has all of the comparison operations <, <=, >, >=. This is at
> odds with the OCL 2.0 specification, which defines only = and <> in the
> OclAny context.
>
> So, in 1.1.x, *all* types in the user model to have the comparison
> operations imposed upon them. Happily, the 1.2 release fixes that :-)
>
> Cheers,
>
> Christian
>
>
> Linda Damus wrote:
>> T does not have any operations, actually. Nor does it correspond to an
>> EClass whose instanceClass is a java.lang.Comparable. I'm not sure
>> why the 1.1.2 release was able to see the < operation from the
>> interface. Given that classes don't inherit features from interfaces,
>> is it because of a defect that has subsequently been fixed in the
>> 1.2.0 release?
>>
>> I've attached a project that contains my .uml model, in case it helps
>> to clarify what I'm doing.
>>
>> Thanks,
>> Linda
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Linda,
>>>
>>> Does the class T happen to define an operation like this?
>>>
>>> compareTo(T) : Integer
>>>
>>> Or, does T correspond to an EClass whose instanceClass is of some
>>> java.lang.Comparable type? In either case, the 1.1.x release would
>>> infer the <(T):Boolean operation even if it wasn't defined. This is
>>> a Java-ism that isn't applicable to OCL, so the 1.2 release corected
>>> that by no longer making this inference. However, the 1.2 API does
>>> allow you to restore the 1.1 behaviour by setting the
>>> ParserOptions.USE_COMPARE_TO_OPERATION option. Try using the
>>> ParserOption.setOption(...) method to set this option on your
>>> environment before you parse (the root environment of your
>>> org.eclipse.ocl.OCL façade is a good choice).
>>>
>>> In any case, the Interface thing is a red herring. Classes don't
>>> inherit features from the interfaces that they implement, so OCL
>>> won't see a < operation in T unless T defines one or inherits it from
>>> another class. Our UML binding has always respected that.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> Linda Damus wrote:
>>>> Should interface operations be visible to their implementing
>>>> classifiers in OCL?
>>>>
>>>> I'm using MDT OCL 1.2.0. I have a UML model containing Interface I
>>>> with a query operation <(param:I):Boolean, and a Class T that
>>>> realizes I (but does not own a corresponding query operation
>>>> <(param:I):Boolean). Another Class C has two attributes a1:T and
>>>> a2:T. Using the OCL Interpreter Example (evaluating for UML at the
>>>> M1 modeling level), I find that the following expression:
>>>>
>>>> self.a1 < self.a2
>>>>
>>>> fails to parse with the error: Cannot find operation (<(T)) for the
>>>> type (T)
>>>>
>>>> Is this the correct behaviour? I've verified that this same
>>>> expression parses without errors in MDT OCL 1.1.2.
>>>>
>>>> Thanks,
>>>> Linda
>>
|
|
|
| Re: Visibility of interface operations to implementing classifiers [message #63152 is a reply to message #63113] |
Tue, 14 October 2008 13:57 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Linda,
This is necessary in order to enable the compatibility option, which
restores the former (incorrect) behaviour. An OCL 2.0 release would
remove them.
The OCLStandardLibraryUtil class should not be used by clients. The
@noreference tag defined by the PDE API Tools should be used to indicate
that (it isn't, currently). The exception to this rule is implementers
of metamodel bindings, but this API is only used in generating the OCL
Standard Library package, which otherwise is loaded by de-serialization
at run-time.
Cheers,
Christian
Linda Damus wrote:
> In MDT OCL 1.2.0, I see that implementation of
> OCLStandardLibraryUtil#createAnyTypeOperations still seems to return <,
> >, <= and >=. Is that correct?
>
> Thanks,
> Linda
>
>
> Christian W. Damus wrote:
>> Hi, Linda,
>>
>> Thanks for the attachment. I debugged it and have surprised myself.
>>
>> The OCL 1.1 release has a bug, which evidently was fixed in 1.2 though
>> I don't remember it. In 1.1, the OclAny type from the OCL Standard
>> Library has all of the comparison operations <, <=, >, >=. This is at
>> odds with the OCL 2.0 specification, which defines only = and <> in
>> the OclAny context.
>>
>> So, in 1.1.x, *all* types in the user model to have the comparison
>> operations imposed upon them. Happily, the 1.2 release fixes that :-)
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Linda Damus wrote:
>>> T does not have any operations, actually. Nor does it correspond to
>>> an EClass whose instanceClass is a java.lang.Comparable. I'm not
>>> sure why the 1.1.2 release was able to see the < operation from the
>>> interface. Given that classes don't inherit features from interfaces,
>>> is it because of a defect that has subsequently been fixed in the
>>> 1.2.0 release?
>>>
>>> I've attached a project that contains my .uml model, in case it helps
>>> to clarify what I'm doing.
>>>
>>> Thanks,
>>> Linda
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Linda,
>>>>
>>>> Does the class T happen to define an operation like this?
>>>>
>>>> compareTo(T) : Integer
>>>>
>>>> Or, does T correspond to an EClass whose instanceClass is of some
>>>> java.lang.Comparable type? In either case, the 1.1.x release would
>>>> infer the <(T):Boolean operation even if it wasn't defined. This is
>>>> a Java-ism that isn't applicable to OCL, so the 1.2 release corected
>>>> that by no longer making this inference. However, the 1.2 API does
>>>> allow you to restore the 1.1 behaviour by setting the
>>>> ParserOptions.USE_COMPARE_TO_OPERATION option. Try using the
>>>> ParserOption.setOption(...) method to set this option on your
>>>> environment before you parse (the root environment of your
>>>> org.eclipse.ocl.OCL façade is a good choice).
>>>>
>>>> In any case, the Interface thing is a red herring. Classes don't
>>>> inherit features from the interfaces that they implement, so OCL
>>>> won't see a < operation in T unless T defines one or inherits it
>>>> from another class. Our UML binding has always respected that.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Linda Damus wrote:
>>>>> Should interface operations be visible to their implementing
>>>>> classifiers in OCL?
>>>>>
>>>>> I'm using MDT OCL 1.2.0. I have a UML model containing Interface I
>>>>> with a query operation <(param:I):Boolean, and a Class T that
>>>>> realizes I (but does not own a corresponding query operation
>>>>> <(param:I):Boolean). Another Class C has two attributes a1:T and
>>>>> a2:T. Using the OCL Interpreter Example (evaluating for UML at the
>>>>> M1 modeling level), I find that the following expression:
>>>>>
>>>>> self.a1 < self.a2
>>>>>
>>>>> fails to parse with the error: Cannot find operation (<(T)) for the
>>>>> type (T)
>>>>>
>>>>> Is this the correct behaviour? I've verified that this same
>>>>> expression parses without errors in MDT OCL 1.1.2.
>>>>>
>>>>> Thanks,
>>>>> Linda
>>>
|
|
|
Goto Forum:
Current Time: Thu Nov 14 07:57:31 GMT 2024
Powered by FUDForum. Page generated in 0.10096 seconds |
] 
Search
Help
Register
Login
Home
