Home » Modeling » OCL » Problem while validating TupleLiteralParts (checkValuePart constraint)
|
| Re: Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55637 is a reply to message #55609] |
Tue, 13 May 2008 23:46   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adolfo,
Find some replies in-line, below.
HTH,
Christian
On Tuesday 05-13-2008 (01:02), Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
> In M7,
> The following TupleLiteralExp throws the following error:
> Tuple {a: Collection(String) = Set{"aString"}, b: String =
> "aString"};
> Error: Validator-ERROR in org.eclipse.ocl.expressions;
> testQVTo.qvto:22 : Tuple literal part (a) type does not match
> property type: (Tuple{a : Collection(String) = Set {'aString'}, b :
> String = 'aString'})
> If I use Set(String) instead, the error dissapears. So it seems that
> the EValidator via the use of TypeUtil.exactTypeMatch method, expects
> to recieve the same type (property and value).
Well, that is how the constraint is specified by the OCL. From 8.3.7
(p. 55):
[1] The type of the attribute is the type of the value expression.
context TupleLiteralPart
inv: attribute.type = value.type
Either OCL intentionally requires exact correspondence, or the
specification of this constraint is in error and should use
Classifier::conformsTo(Classifier).
> It seems that it's a bug, isn't it?.
Well, IMHO the conformsTo() semantics would be more appropriate.
However, with the EValidator I am being careful to implement as much
as possible the OCL Specification's constraints to the letter.
Obviously, where the actual OCL expressions in the text are not
well-formed, I have to make a correction, but there is no such
problem, here.
I have submitted an issue to the OCL RTF proposing an amendment to
conforms-to semantics.
> Does this constraint implemented by EValidator have the same
> behaviour than the ValidationVisitor one?....it should...
No, it does not. The ValidationVisitor is not simply delegating to
the EValidator for a number of reasons, this being but one.
> Could you put some light on my doubts?
I hope I did.
> Cheers,
> Adolfo
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
| Re: Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55766 is a reply to message #55637] |
Wed, 14 May 2008 10:16 |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thank you for the aclaration. Definetely, I have understood the problem
and I agree with you that conformsTo is more appropriate. That's the
origin of my confusion.
Cheers,
Adolfo.
Christian W. Damus escribió:
> Hi, Adolfo,
>
> Find some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> On Tuesday 05-13-2008 (01:02), Adolfo Sánchez-Barbudo Herrera wrote:
>> Hi Christian,
>
>> In M7,
>
>> The following TupleLiteralExp throws the following error:
>
>> Tuple {a: Collection(String) = Set{"aString"}, b: String =
>> "aString"};
>
>> Error: Validator-ERROR in org.eclipse.ocl.expressions;
>> testQVTo.qvto:22 : Tuple literal part (a) type does not match
>> property type: (Tuple{a : Collection(String) = Set {'aString'}, b :
>> String = 'aString'})
>
>> If I use Set(String) instead, the error dissapears. So it seems that
>> the EValidator via the use of TypeUtil.exactTypeMatch method, expects
>> to recieve the same type (property and value).
>
> Well, that is how the constraint is specified by the OCL. From 8.3.7
> (p. 55):
>
> [1] The type of the attribute is the type of the value expression.
> context TupleLiteralPart
> inv: attribute.type = value.type
>
> Either OCL intentionally requires exact correspondence, or the
> specification of this constraint is in error and should use
> Classifier::conformsTo(Classifier).
>> It seems that it's a bug, isn't it?.
>
> Well, IMHO the conformsTo() semantics would be more appropriate.
> However, with the EValidator I am being careful to implement as much
> as possible the OCL Specification's constraints to the letter.
> Obviously, where the actual OCL expressions in the text are not
> well-formed, I have to make a correction, but there is no such
> problem, here.
>
> I have submitted an issue to the OCL RTF proposing an amendment to
> conforms-to semantics.
>> Does this constraint implemented by EValidator have the same
>> behaviour than the ValidationVisitor one?....it should...
>
> No, it does not. The ValidationVisitor is not simply delegating to
> the EValidator for a number of reasons, this being but one.
>> Could you put some light on my doubts?
>
> I hope I did.
>> Cheers,
>> Adolfo
>
>
>
>
>
>
|
|
| |
| Re: Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55928 is a reply to message #55847] |
Thu, 15 May 2008 19:35 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Felix,
Yes, you are correct. Tuple parts are unordered, and conformance of
tuple types is determined by conformance of their parts (which works
because tuples, like all OCL data types, are immutable).
Cheers,
Christian
Felix Dorner wrote:
> Hi,
>
> not directly related to the original question, but to Ocl Tuple types
> and their conformance to each other. Suppose Car < Vehicle. Am I right
> seeing that for the two types:
>
> bigger = Tuple { a: Vehicle , b: Integer }
> smaller = Tuple { b: Integer , a: Car}
>
> smaller conforms to bigger?
>
> The essence is, that the parts are not checked for conformance via their
> position in the tuple, but via their name/label?
>
>
>
> Felix
|
|
|
Goto Forum:
Current Time: Thu Nov 14 07:57:47 GMT 2024
Powered by FUDForum. Page generated in 0.03837 seconds |
] 
Search
Help
Register
Login
Home
