Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » [QVT] Collection type cast @Helios
[QVT] Collection type cast @Helios [message #544696] Mon, 05 July 2010 09:50 Go to next message
Christian Saad is currently offline Christian SaadFriend
Messages: 38
Registered: July 2009
Member
Hi,

after some research it seems that it is a well known problem that one cannot cast to a Collection type in OCL, but strangely this worked for me with Galileo and I only get an error since switching to Helios.

In my use case I generate and parse a QVT library at runtime. Queries in the library use a generic (static) Java black box method with the return type Object to retrieve some input values. The actual type of the returned value depends on the given parameter and therefore must be cast to the return type of the query:

query endnode::out_connectors_qvt() : Set(String)
{return java_attribute_accessor(self,"out_connectors_qvt").oclAsType(Set(String));}

As I mentioned, this was no problem as long as I used Galileo, but Helios now gives me:
Unrecognized variable: (Set), Line 288: Cannot find operation (oclAsType(OclInvalid)) for the type (OclAny)

It would be difficult to impossible to actually ensure a Java blackbox method exists for each possible return type, since the return type itself is specified at runtime by the user.
Is there a way to enforce the old behavior (even if it doesn't conform to OCL standard)?

Thanks,
Chris
Re: [QVT] Collection type cast @Helios [message #544890 is a reply to message #544696] Mon, 05 July 2010 22:04 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 162
Registered: July 2009
Senior Member
Hi Christian,

It's quite surprisingly that such code was valid in Galileo.
Expression ".oclAsType(Set(String))" has syntax error. Correct one is
".oclAsType(Set{String})" (note round brackets is changed with braces).

For Helios release type checking was constrained to confirm to
specification and there's no way to revert behavior back. However latest
OCL specification allows such type reinterpretation so in next release
that code might be valid again.

For Helios release I can suggest to provide two methods in Java black-box:

public Object getAnyObject() {
return ...
}

public org.eclipse.ocl.util.Bag<Object> getAnyObjectList() {
return org.eclipse.ocl.util.CollectionUtil.createNewBag(...);
}

Second function can be used to return any type casted to Collection type
so in QVT script actual conversion can be applied:
getAnyObjectList()->asSet();


Regards,
Sergey.

C. Saad wrote:
> Hi,
>
> after some research it seems that it is a well known problem that one
> cannot cast to a Collection type in OCL, but strangely this worked for
> me with Galileo and I only get an error since switching to Helios.
>
> In my use case I generate and parse a QVT library at runtime. Queries in
> the library use a generic (static) Java black box method with the return
> type Object to retrieve some input values. The actual type of the
> returned value depends on the given parameter and therefore must be cast
> to the return type of the query:
>
> query endnode::out_connectors_qvt() : Set(String)
> {return
> java_attribute_accessor(self,"out_connectors_qvt").oclAsType(Set(String));}
>
> As I mentioned, this was no problem as long as I used Galileo, but
> Helios now gives me: Unrecognized variable: (Set), Line 288: Cannot find
> operation (oclAsType(OclInvalid)) for the type (OclAny)
>
> It would be difficult to impossible to actually ensure a Java blackbox
> method exists for each possible return type, since the return type
> itself is specified at runtime by the user.
> Is there a way to enforce the old behavior (even if it doesn't conform
> to OCL standard)?
>
> Thanks,
> Chris
Re: [QVT] Collection type cast @Helios [message #544974 is a reply to message #544890] Tue, 06 July 2010 09:05 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4187
Registered: July 2009
Senior Member
Hi Christian, Sergey

(The OCL 2.0 and 2.2 specification do not actually allow type-valued
expressions at all, so any form of oclType(SomeType) is erroneous!
The specification fix should be in OCL 2.3.)

This bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=299957 which
should be fixed in Indigo. The discussion has a trivial fix to restore
the parsing that was never exercised and so fell out with the grammar
simplification. The underlying evaluation has never been exercised so
I would expect that it needs enhancement.

[No. oclAsType(Set{String}) is a type change to a Set literal comprising
a type element value, which should always be a validation
error. Definitely not what you want.]

Regards

Ed Willink

On 05/07/2010 23:04, Sergey Boyko wrote:
> Hi Christian,
>
> It's quite surprisingly that such code was valid in Galileo.
> Expression ".oclAsType(Set(String))" has syntax error. Correct one is
> ".oclAsType(Set{String})" (note round brackets is changed with braces).
>
> For Helios release type checking was constrained to confirm to
> specification and there's no way to revert behavior back. However latest
> OCL specification allows such type reinterpretation so in next release
> that code might be valid again.
>
> For Helios release I can suggest to provide two methods in Java black-box:
>
> public Object getAnyObject() {
> return ...
> }
>
> public org.eclipse.ocl.util.Bag<Object> getAnyObjectList() {
> return org.eclipse.ocl.util.CollectionUtil.createNewBag(...);
> }
>
> Second function can be used to return any type casted to Collection type
> so in QVT script actual conversion can be applied:
> getAnyObjectList()->asSet();
>
>
> Regards,
> Sergey.
>
> C. Saad wrote:
>> Hi,
>>
>> after some research it seems that it is a well known problem that one
>> cannot cast to a Collection type in OCL, but strangely this worked for
>> me with Galileo and I only get an error since switching to Helios.
>>
>> In my use case I generate and parse a QVT library at runtime. Queries
>> in the library use a generic (static) Java black box method with the
>> return type Object to retrieve some input values. The actual type of
>> the returned value depends on the given parameter and therefore must
>> be cast to the return type of the query:
>>
>> query endnode::out_connectors_qvt() : Set(String)
>> {return
>> java_attribute_accessor(self,"out_connectors_qvt").oclAsType(Set(String));}
>>
>>
>> As I mentioned, this was no problem as long as I used Galileo, but
>> Helios now gives me: Unrecognized variable: (Set), Line 288: Cannot
>> find operation (oclAsType(OclInvalid)) for the type (OclAny)
>>
>> It would be difficult to impossible to actually ensure a Java blackbox
>> method exists for each possible return type, since the return type
>> itself is specified at runtime by the user.
>> Is there a way to enforce the old behavior (even if it doesn't conform
>> to OCL standard)?
>>
>> Thanks,
>> Chris
Re: [QVT] Collection type cast @Helios [message #544987 is a reply to message #544696] Tue, 06 July 2010 09:32 Go to previous messageGo to next message
Christian Saad is currently offline Christian SaadFriend
Messages: 38
Registered: July 2009
Member
Hi Sergey, Ed,

thanks for the ideas for possible workarounds, I'll try to implement them. Is there perhaps already a branch for OCL 2.3 support which I could use before the next Eclipse release? Otherwise, if the suggested solutions don't work for me, I'll have to switch back to the old version.

Regards,
Chris
Re: [QVT] Collection type cast @Helios [message #545110 is a reply to message #544974] Tue, 06 July 2010 16:01 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 162
Registered: July 2009
Senior Member
Hi Ed ,

Some comments are in-lined below.

Regards,
sergey

Ed Willink wrote:
> Hi Christian, Sergey
>
> (The OCL 2.0 and 2.2 specification do not actually allow type-valued
> expressions at all, so any form of oclType(SomeType) is erroneous!
> The specification fix should be in OCL 2.3.)

I didn't get this. OCL 2.0 specification states that (section 7.4.6
"Re-typing or Casting", section 7.5.9 "Predefined properties on All
Objects") that for example "oclAsType (t : OclType) : instance of
OclType" operation is defined for objects.
Such operation is not defined for the Collection types so for example
"collection->oclAsType(OclType)" is not defined
(collection.oclAsType(OclType) performs on collection's elements).

>
> This bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=299957 which
> should be fixed in Indigo. The discussion has a trivial fix to restore
> the parsing that was never exercised and so fell out with the grammar
> simplification. The underlying evaluation has never been exercised so
> I would expect that it needs enhancement.
>
> [No. oclAsType(Set{String}) is a type change to a Set literal comprising
> a type element value, which should always be a validation
> error. Definitely not what you want.]

Yes, I realized that rule
CollectionTypeIdentifierCS '{' CollectionLiteralPartsCSopt '}' composes
literal expression (CollectionLiteralExpCS) so my assumption was wrong.

Expression "collection->oclIsKindOf(Set(String))" should be interpreted
as "collection->oclIsKindOf(OclType)" but that is not so due to
inconsistent grammar rules that leads to syntax error now.

>
> Regards
>
> Ed Willink
>
> On 05/07/2010 23:04, Sergey Boyko wrote:
>> Hi Christian,
>>
>> It's quite surprisingly that such code was valid in Galileo.
>> Expression ".oclAsType(Set(String))" has syntax error. Correct one is
>> ".oclAsType(Set{String})" (note round brackets is changed with braces).
>>
>> For Helios release type checking was constrained to confirm to
>> specification and there's no way to revert behavior back. However latest
>> OCL specification allows such type reinterpretation so in next release
>> that code might be valid again.
>>
>> For Helios release I can suggest to provide two methods in Java
>> black-box:
>>
>> public Object getAnyObject() {
>> return ...
>> }
>>
>> public org.eclipse.ocl.util.Bag<Object> getAnyObjectList() {
>> return org.eclipse.ocl.util.CollectionUtil.createNewBag(...);
>> }
>>
>> Second function can be used to return any type casted to Collection type
>> so in QVT script actual conversion can be applied:
>> getAnyObjectList()->asSet();
>>
>>
>> Regards,
>> Sergey.
>>
>> C. Saad wrote:
>>> Hi,
>>>
>>> after some research it seems that it is a well known problem that one
>>> cannot cast to a Collection type in OCL, but strangely this worked for
>>> me with Galileo and I only get an error since switching to Helios.
>>>
>>> In my use case I generate and parse a QVT library at runtime. Queries
>>> in the library use a generic (static) Java black box method with the
>>> return type Object to retrieve some input values. The actual type of
>>> the returned value depends on the given parameter and therefore must
>>> be cast to the return type of the query:
>>>
>>> query endnode::out_connectors_qvt() : Set(String)
>>> {return
>>> java_attribute_accessor(self,"out_connectors_qvt").oclAsType(Set(String));}
>>>
>>>
>>>
>>> As I mentioned, this was no problem as long as I used Galileo, but
>>> Helios now gives me: Unrecognized variable: (Set), Line 288: Cannot
>>> find operation (oclAsType(OclInvalid)) for the type (OclAny)
>>>
>>> It would be difficult to impossible to actually ensure a Java blackbox
>>> method exists for each possible return type, since the return type
>>> itself is specified at runtime by the user.
>>> Is there a way to enforce the old behavior (even if it doesn't conform
>>> to OCL standard)?
>>>
>>> Thanks,
>>> Chris
>
Re: [QVT] Collection type cast @Helios [message #545124 is a reply to message #545110] Tue, 06 July 2010 17:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4187
Registered: July 2009
Senior Member
Hi Sergey

The problem is that the OCL specification omits the TypeExpCS subclause
for a type literal in the normative clause 9, so expressions
involving types are unparseable. (To confuse matters further, I wrote
a resolution introducing a TypeLiteralExpCS to solve this problem. My
proposed resolution has been approved for OCL 2.3, so I shall now have
to correct one of my own approved resolutions. I've been delaying
because I'm pretty sure that TypeExpCS and TypeLiteralExpCS really need
to be a ModelElementLiteralCS, so for instance that you can do the fully
qualified

if something.oclType() = String

rather than the unqualified

if something.oclType().name = 'String')

The non-normative clause 7 makes it very clear what should happen and
so most OCL implementations deviate from the normative intuitively.

Regards

Ed

On 06/07/2010 17:01, Sergey Boyko wrote:
> Hi Ed ,
>
> Some comments are in-lined below.
>
> Regards,
> sergey
>
> Ed Willink wrote:
>> Hi Christian, Sergey
>>
>> (The OCL 2.0 and 2.2 specification do not actually allow type-valued
>> expressions at all, so any form of oclType(SomeType) is erroneous!
>> The specification fix should be in OCL 2.3.)
>
> I didn't get this. OCL 2.0 specification states that (section 7.4.6
> "Re-typing or Casting", section 7.5.9 "Predefined properties on All
> Objects") that for example "oclAsType (t : OclType) : instance of
> OclType" operation is defined for objects.
> Such operation is not defined for the Collection types so for example
> "collection->oclAsType(OclType)" is not defined
> (collection.oclAsType(OclType) performs on collection's elements).
>
>>
>> This bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=299957 which
>> should be fixed in Indigo. The discussion has a trivial fix to restore
>> the parsing that was never exercised and so fell out with the grammar
>> simplification. The underlying evaluation has never been exercised so
>> I would expect that it needs enhancement.
>>
>> [No. oclAsType(Set{String}) is a type change to a Set literal
>> comprising a type element value, which should always be a validation
>> error. Definitely not what you want.]
>
> Yes, I realized that rule
> CollectionTypeIdentifierCS '{' CollectionLiteralPartsCSopt '}' composes
> literal expression (CollectionLiteralExpCS) so my assumption was wrong.
>
> Expression "collection->oclIsKindOf(Set(String))" should be interpreted
> as "collection->oclIsKindOf(OclType)" but that is not so due to
> inconsistent grammar rules that leads to syntax error now.
>
>>
>> Regards
>>
>> Ed Willink
>>
>> On 05/07/2010 23:04, Sergey Boyko wrote:
>>> Hi Christian,
>>>
>>> It's quite surprisingly that such code was valid in Galileo.
>>> Expression ".oclAsType(Set(String))" has syntax error. Correct one is
>>> ".oclAsType(Set{String})" (note round brackets is changed with braces).
>>>
>>> For Helios release type checking was constrained to confirm to
>>> specification and there's no way to revert behavior back. However latest
>>> OCL specification allows such type reinterpretation so in next release
>>> that code might be valid again.
>>>
>>> For Helios release I can suggest to provide two methods in Java
>>> black-box:
>>>
>>> public Object getAnyObject() {
>>> return ...
>>> }
>>>
>>> public org.eclipse.ocl.util.Bag<Object> getAnyObjectList() {
>>> return org.eclipse.ocl.util.CollectionUtil.createNewBag(...);
>>> }
>>>
>>> Second function can be used to return any type casted to Collection type
>>> so in QVT script actual conversion can be applied:
>>> getAnyObjectList()->asSet();
>>>
>>>
>>> Regards,
>>> Sergey.
>>>
>>> C. Saad wrote:
>>>> Hi,
>>>>
>>>> after some research it seems that it is a well known problem that one
>>>> cannot cast to a Collection type in OCL, but strangely this worked for
>>>> me with Galileo and I only get an error since switching to Helios.
>>>>
>>>> In my use case I generate and parse a QVT library at runtime. Queries
>>>> in the library use a generic (static) Java black box method with the
>>>> return type Object to retrieve some input values. The actual type of
>>>> the returned value depends on the given parameter and therefore must
>>>> be cast to the return type of the query:
>>>>
>>>> query endnode::out_connectors_qvt() : Set(String)
>>>> {return
>>>> java_attribute_accessor(self,"out_connectors_qvt").oclAsType(Set(String));}
>>>>
>>>>
>>>>
>>>> As I mentioned, this was no problem as long as I used Galileo, but
>>>> Helios now gives me: Unrecognized variable: (Set), Line 288: Cannot
>>>> find operation (oclAsType(OclInvalid)) for the type (OclAny)
>>>>
>>>> It would be difficult to impossible to actually ensure a Java blackbox
>>>> method exists for each possible return type, since the return type
>>>> itself is specified at runtime by the user.
>>>> Is there a way to enforce the old behavior (even if it doesn't conform
>>>> to OCL standard)?
>>>>
>>>> Thanks,
>>>> Chris
>>
Re: [QVT] Collection type cast @Helios [message #641274 is a reply to message #544696] Wed, 24 November 2010 17:22 Go to previous message
Christian Saad is currently offline Christian SaadFriend
Messages: 38
Registered: July 2009
Member
Hi again,

ok, so I guess it will still be some time until this is included in the spec&implementation.
In the meantime I thought I'd try to create a workaround by dynamically generating and compiling a Java black box class (using the Eclipse compiler) with methods that return the exact type which is expected by the OCL parser.
Unfortunately, I found no way to dynamically register a black box class at run time, particularly one the only exists in memory.
It would be great if someone could give me a hint on how to accomplish this (or some other workaround, problem with the blackbox solution is also that I cannot use dynamic EClasses as returntypes).

Regards,
Chris
Previous Topic:[ATL] Message to be deleted !!!!!!!!!
Next Topic:[ATL] How to launch Query by program in ATL3 API?
Goto Forum:
  


Current Time: Fri Dec 19 09:25:10 GMT 2014

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

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