Home » Modeling » OCL » Comparison operators
|
| Re: Comparison operators [message #56334 is a reply to message #56317] |
Wed, 21 May 2008 15:45   |
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 #56365 is a reply to message #56350] |
Wed, 21 May 2008 16:51 |
| 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 19:49 |
 Felix Dorner
Messages: 676
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..
|
|
| |
Goto Forum:
Current Time: Sun Sep 08 14:10:59 GMT 2024
Powered by FUDForum. Page generated in 0.04188 seconds |
] 
Search
Help
Register
Login
Home
