|Re: for loop Sequence type mismatch [message #1738823 is a reply to message #1738816]
||Mon, 25 July 2016 08:55
| Ed Willink
Registered: July 2009
IMHO this is a use case that should work too.
The revised Pivot OCL implementation associates an optional
behavioralType with each DataType, so that e.g. ELong has an Integer
behavioralType. The OCLforUML profile supports configuring this for
arbitrary user types. For DataTypes with an instance class, the known
Java types are mapped to Inreger / Real.
The use of isInstance() for DataTypes is very suspect, so perhaps you
have a bug to fix (or to report against the Classic OCL).
My view of precision in OCL (and OCL-extending tools) is:
a) User types are loaded from model
b) OCL evaluations proceed, using the behavioral type where necessary
resulting in Integer/Real internal working variables
c) OCL results are saved to the model with Integer/Real
validated/converted to fit the model element's type
On 25/07/2016 09:07, Laurent Goubet wrote:
>> The second was that my "arrayDim.size" type was metamodeled as an
>> "Elong" which wasn't compatible with Acceleo "for" loop or "let"
>> statement assignments for some reason. I needed to switch the
>> metamodel of the size to "Int [int]" in my ecore model.
>> Any idea why casting an Elong to an Integer in acceleo would cause a
>> let or for loop statement not to execute? Just curious for my own
> This is your real issue. EMF will not consider an integer to be
> compatible with type ELong, so Acceleo won't either. That is due to
> how "isInstance" checks are implemented in EMF, you can take a look at
> EClassifier.isInstance(Object) for your information. Basically, for
> the "ELong" classifier, the only object that will be considered
> compatible are instances of "java.lang.Long", which integers are not.
> Laurent Goubet
This email has been checked for viruses by Avast antivirus software.
Powered by FUDForum
. Page generated in 0.01984 seconds