| Comparison operators [message #56317] |
Wed, 21 May 2008 04:24  |
Eclipse User |
|
|
|
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  |
| 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 12: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 15:49 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
>>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..
|
|
|
Powered by
FUDForum. Page generated in 0.02930 seconds
Home