|
|
Re: for loop Sequence type mismatch [message #1738708 is a reply to message #1738641] |
Fri, 22 July 2016 12:56 |
|
Hi,
Please copy/paste the exact error you get, along with its stack trace if any.
Please also try and check if you actually get the result you expect from your query call (could be invalid for example) with a printing statement such as this:
[query public dimensionSize(anArrayDim : ArrayDimension) : Integer = anArrayDim.size /]
[template public cppVariablePrintout(field : Array)]
[field.dimensions->first().dimensionSize()/]
[for (Sequence{1..field.dimensions->first().dimensionSize()})]
[field.dimensions->first().dimensionSize()/]
[/for]
[/template]
Laurent Goubet
Obeo
|
|
|
|
|
|
Re: for loop Sequence type mismatch [message #1738816 is a reply to message #1738802] |
Mon, 25 July 2016 08:07 |
|
Quote:Ok I got it working. I actually had two problems. The first was metamodel Schizophrenia within my own metamodel, which defined a class called "Integer". I can see now why that was very bad.
Actually, this is a use case that should work in Acceleo if I'm not mistaken.
Quote:
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 learning.
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
Obeo
|
|
|
Re: for loop Sequence type mismatch [message #1738823 is a reply to message #1738816] |
Mon, 25 July 2016 08:55 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi Laurent
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
Regards
Ed Willink
On 25/07/2016 09:07, Laurent Goubet wrote:
> Quote:
>> 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
>> learning.
>
>
> 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
> Obeo
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
|
|
|
Powered by
FUDForum. Page generated in 0.03883 seconds