Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Comparison operators
Comparison operators [message #56317] Wed, 21 May 2008 04:24 Go to next message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Hei,

From reading the spec. Is it always valid to compare (=) an x of type X against
an y of type Y, given X and Y conform to OclAny? Especially, it is not checked
if X conforms to Y or Y conforms to X, so:

"hello" = 5

is a well formed OCL expression?
Felix
Re: Comparison operators [message #56334 is a reply to message #56317] Wed, 21 May 2008 11:45 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Felix,

That is the way I read the spec, because = is defined for OclAny. It is
also defined separately for types that do not conform to OclAny, such as
the collection types and the tuple types.

The parser used to over-constrain this operation, checking that the
arguments are of related types, but that is fixed in the 1.2 release.

Cheers,

Christian

Felix Dorner wrote:
> Hei,
>
> From reading the spec. Is it always valid to compare (=) an x of type X
> against an y of type Y, given X and Y conform to OclAny? Especially, it
> is not checked if X conforms to Y or Y conforms to X, so:
>
> "hello" = 5
>
> is a well formed OCL expression?
> Felix
>
>
>
>
>
Re: Comparison operators [message #56350 is a reply to message #56334] Wed, 21 May 2008 12:34 Go to previous messageGo to next message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Christian W. Damus wrote:
> Hi, Felix,
>
> That is the way I read the spec, because = is defined for OclAny. It is
> also defined separately for types that do not conform to OclAny, such as
> the collection types and the tuple types.
> The parser used to over-constrain this operation, checking that the
> arguments are of related types, but that is fixed in the 1.2 release.

Okay, so the good news is that we have the same view on that. Do you know why
the collection types are actually NOT subtypes of OclAny?

This seems confusing.

Felix
Re: Comparison operators [message #56365 is a reply to message #56350] Wed, 21 May 2008 12:51 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Felix,

I think it's just because they are values, not objects. Thus, a lot of
the operations defined for OclAny just don't make sense (oclIsNew,
oclIsUndefined, oclIsInState, etc.)

Cheers,

Christian

Felix Dorner wrote:
> Christian W. Damus wrote:
>> Hi, Felix,
>>
>> That is the way I read the spec, because = is defined for OclAny. It
>> is also defined separately for types that do not conform to OclAny,
>> such as the collection types and the tuple types.
>> The parser used to over-constrain this operation, checking that the
>> arguments are of related types, but that is fixed in the 1.2 release.
>
> Okay, so the good news is that we have the same view on that. Do you
> know why the collection types are actually NOT subtypes of OclAny?
>
> This seems confusing.
>
> Felix
Re: Comparison operators [message #56389 is a reply to message #56365] Wed, 21 May 2008 15:49 Go to previous messageGo to next message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Christian W. Damus wrote:
> Hi, Felix,
>
> I think it's just because they are values, not objects. Thus, a lot of
> the operations defined for OclAny just don't make sense (oclIsNew,
> oclIsUndefined, oclIsInState, etc.)

Yeah, but the primitive types are also values, and, in contrast, conform to OclAny.

Maybe MOF based models do not support the concept of redefinition? Then it
wouln't be it wouldn't be possible to redefine the "=" operator for the
collections..
Re: Comparison operators [message #56547 is a reply to message #56365] Fri, 23 May 2008 04:41 Go to previous message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
>>Do you
>> know why the collection types are actually NOT subtypes of OclAny?

I found it, p. 199:

A simple set inclusion semantics for subtype relationships as
described in the next section would not be possible due to cyclic domain
definitions if OclAny were the supertype of
Set(OclAny).

Now I have to find out what that means..
Previous Topic:Bug in OCLAbstractAnalyzer
Next Topic:ocl collection
Goto Forum:
  


Current Time: Fri Aug 22 13:59:00 EDT 2014

Powered by FUDForum. Page generated in 0.16631 seconds