 ATL does not like EList in operation parameters [message #1748495] |
Wed, 23 November 2016 15:36  |
 Leonardo Montecchi
Messages: 10
Registered: September 2013 |
Junior Member |
|
|
Hi all,
I am writing some transformations between metamodels that I defined using Ecore.
In one of those metamodels I defined some operations, using OCL. In particular I defined the following operation:
evaluate(assignments tmdl::core::Assignment[*]) : ecore::EInt
This translates into the following signature from the generated code:
int evaluate(EList<Assignment> assignments);
ATL correctly recognizes the existence of this operation, but it throws an exception every time I try to call it using a collection of 'Assignment' objects as a parameter, e.g.:
value <- tm.value.evaluate(TMDLEX!Assignment.allInstances()->asSequence())
throws:
org.eclipse.m2m.atl.engine.emfvm.VMException: Operation not found: template!<unnamed>.evaluate(java.util.ArrayList)
It appears that ATL is not able to match EList objects against its collections types. I am aware of the genmodel option to "Suppress EMF Types", and in fact it works correctly if I select that option. However I am afraid of the impact of this option, which as I understand is not recommended.
Also, it seems more like a bug in ATL, because it is able to properly handle EList objects in other situations, for example as fields of model elements.
Do you have any suggestions?
Thanks,
Leonardo.
Leonardo Montecchi
Instituto de Computação, UNICAMP
http://ic.unicamp.br/~leonardo
http://laser.ic.unicamp.br/
|
|
|
| Re: ATL does not like EList in operation parameters [message #1748512 is a reply to message #1748495] |
Wed, 23 November 2016 20:08  |
|
The EList collection type is fine as a method return type, but as input parameter type it is too restrictive. You should not use the specific EList type for input parameters, but rather the general List or Collection type.
EDIT: I've verified that the standard EMF code generator will always use EList for anything with a multiplicity higher than 1, including input parameters (see attached Eclipse project). This is indeed a mismatch, and we may fix this in the latest EMFTVM runtime.
There is a workaround in EMF: you can specify java.util.List as a new EDataType in your metamodel, and add an ETypeParameter "T" as child. You can then use that type for an input parameter, using the standard [0-1] multiplicity, and bind the ETypeParameter T to the Assignment EClass. This is what the 'otherOperation" in the attached Eclipse project does.
Cheers,
Dennis
[Updated on: Wed, 23 November 2016 20:32] Report message to a moderator |
|
|
|
| Re: ATL does not like EList in operation parameters [message #1748640 is a reply to message #1748515] |
Fri, 25 November 2016 15:18 |
Leonardo Montecchi
Messages: 10
Registered: September 2013 |
Junior Member |
|
|
Hi Dennis,
Thank you for your quick and accurate response!
I did not know about EMFTVM, I tried it and it seems to solve that problem about ELists. However, I am having several other issues, it seems that the compiler is more strict than the "normal" one, is it true?
I managed to solve most of them, but now I am struggling with the following problem.
I have a lazy abstract rule that looks like the following:
lazy abstract rule Marking {
from
tm : SANT!Marking
to
m : SAN!Marking
}
where SAN!Marking and SANT!Marking are both abstract classes, from different metamodels. This rule is then extended by several other lazy rules. This was working perfectly with the normal compiler, but now I get:
org.eclipse.m2m.atl.emftvm.util.VMException: java.lang.IllegalArgumentException: The class 'Marking' is not a valid classifier
Any suggestions?
Thanks,
Leonardo.
Leonardo Montecchi
Instituto de Computação, UNICAMP
http://ic.unicamp.br/~leonardo
http://laser.ic.unicamp.br/
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05500 seconds
] 
Search
Help
Register
Login
Home
