Home » Archived » M2M (model-to-model transformation) » [QVT] Collection type cast @Helios
|
| Re: [QVT] Collection type cast @Helios [message #544890 is a reply to message #544696] |
Mon, 05 July 2010 22:04   |
 Sergey Boyko
Messages: 171
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 |
Ed Willink
Messages: 7655
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 #545110 is a reply to message #544974] |
Tue, 06 July 2010 16:01 |
Sergey Boyko
Messages: 171
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 |
Ed Willink
Messages: 7655
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
>>
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 19:42:11 GMT 2024
Powered by FUDForum. Page generated in 0.04104 seconds |
] 
Search
Help
Register
Login
Home
