Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Problem while validating TupleLiteralParts (checkValuePart constraint)
Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55609] Tue, 13 May 2008 17:02 Go to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
Registered: July 2009
Senior Member
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).

It seems that it's a bug, isn't it?.
Does this constraint implemented by EValidator have the same behaviour
than the ValidationVisitor one?....it should...

Could you put some light on my doubts?

Cheers,
Adolfo
Re: Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55637 is a reply to message #55609] Tue, 13 May 2008 23:46 Go to previous messageGo to next message
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 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo Herrera
Messages: 253
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 #55847 is a reply to message #55637] Thu, 15 May 2008 15:15 Go to previous messageGo to next message
Felix Dorner is currently offline Felix Dorner
Messages: 676
Registered: July 2009
Senior Member
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
Re: Problem while validating TupleLiteralParts (checkValuePart constraint) [message #55928 is a reply to message #55847] Thu, 15 May 2008 19:35 Go to previous message
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
Previous Topic:About EValidator checkArgumentConform constraint
Next Topic:implementation for checking invalid select expressions
Goto Forum:
  


Current Time: Fri Oct 24 23:14:13 GMT 2014

Powered by FUDForum. Page generated in 0.11278 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software