Eclipse Community Forums: M2T (model-to-text transformation) » [Acceleo] Problem of type with empty collections

Home » Modeling » M2T (model-to-text transformation) » [Acceleo] Problem of type with empty collections

[Acceleo] Problem of type with empty collections [message #1795872]

Mon, 01 October 2018 11:01

Eclipse User

Hi !

I'm using Acceleo 3.4.1, and I've found a strange behaviour with the queries defined in the context of a Collection.

Example :

[query public test(aSet : Set(String)) : Set(String) = aSet->including('a')/]

If you try to call this query on an empty Set, like this :

[Set(String){}->test()/]

you get this error of compilation : "Cannot find operation (test()) for the type (Set(OclVoid))"

The only solution I have found is to call the filter(String) operation on the empty Set, like this :

[Set(String){}->filter(String)->test()/]

Is there a better solution to get round this problem ?

I don't know yet if the problem is still present on the last version of Acceleo, I will test it.

Thanks !

Regards.

Re: [Acceleo] Problem of type with empty collections [message #1795878 is a reply to message #1795872]

Mon, 01 October 2018 12:23

Eclipse User

Hi

The OCL specification is very weak on the details of 'templated' types.

This is basically OMG Issue 12953. Unfortunately the OCL 2.3 RTF does not seem to be easily accessible at the moment.

If you are an OMG member you can access the PDF as ptc/2010-11-06, otherwise the raw ASCII text is at the top/bottom of https://www.omg.org/issues/issue12953.txt

The proposed resolution involved some type back propagation that I have come to realize is stupid. I doubt tools do it. The ability to declare more explicitly is better supported. The Pivot OCL is much better, the Classic OCL underpinning Acceleo is only slightly better.

The idiocy is the idea that since OclVoid conforms to all types, then all features of all types are accessible on an OclVoid/OclInvalid. i.e. null.name is syntactically just an ambiguity between all types with a name feature even though evaluation of null.name is of course invalid.

Realistically, if you find something that works around the ambiguous inferred empty collection type, use it.

Regards

Ed Willink

Re: [Acceleo] Problem of type with empty collections [message #1795885 is a reply to message #1795878]

Mon, 01 October 2018 19:28

Eclipse User

OMG ! Seriously ?!

I can't understand where is the ambiguity when you write :

Set(String){}

It is clearly written that this empty Set shall receive String typed elements only, so there is no reason to be interpreted as a Set(OclVoid).

I've just read the last specifications of OCL (version 2.4), and the syntax :

<collectionKind>(<collectionType>){}

is not a valid one, the part "(<collectionType)" is not allowed according to these specifications, but is allowed by Acceleo however.

So is this just a syntax accepted by Acceleo only and having no effect with OCL, or the used implementation of OCL allows this too but ignore it ?

It's really a shame... This lack is totally incomprehensible. -_-°
So I keep my workaround by using the filter operation... I won't have better... :/
And logically, I suppose :

Set{}.oclAsType(String)

should be a workaround too...

Regards.

[Updated on: Mon, 01 October 2018 19:39] by Moderator

Re: [Acceleo] Problem of type with empty collections [message #1795904 is a reply to message #1795885]

Tue, 02 October 2018 04:12

Eclipse User

Hi

OCL 2.3 extended the CollectionLiteralExp syntax to allow the qualifier. Ouch! The extension is not present in OCL 2.4. https://issues.omg.org/browse/OCL25-215 raised.

The Classic OCL grammar was changed in 2009 to parse the extra template argument, anticipating/prototyping OCL 2.3. However template type resolution with Classic OCL takes a very narrow view on how the magic "T" in library operations should be resolved; it must be one of the argument types.

(The Pivot OCL takes a template type view that "T" is a type wildcard and so may be anything that argument types conform to; just like Java.)

In more detail, I think your problem is that although Set(String){} is successfully parsed, the Classic OCL does not have a templated type declaration. Rather it determines the magic "T" type from the content and so reverts to Set(OclVoid) and the subsequent match for a Set(String) operation fails in its type conversion. Fixing this kind of deep language+implementation design problem causes horrendous legacy ripples and was one of my motivations in producing the Pivot OCL that learns from the Classic OCL problems. Pivot OCL prototypes a 'next' OCL in which Set(String) is a UML templated type rather than a magic macro-type.

Regards

Ed Willink

Previous Topic:	Papyrus SysML model to text
Next Topic:	[Acceleo]Run Problem

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 15 12:51:50 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter