| [Acceleo 3] ownedElement + filter + reject : unexpected behavior [message #557488] |
Tue, 07 September 2010 16:42  |
 Yannick Duchene (Hibou57)
Messages: 50
Registered: September 2010
Location: Metz (France - Europe) |
Member |
|
|
Hi all,
For this test, you will just need a tiny UML model : a class diagram containing one package and one or more classes with public visibility in that package.
First script sample :
[let classes : Sequence(Class) =
pkg.eAllContents(Class)->reject
(c : Class |
c.visibility <> VisibilityKind::public)]
[for (c : Class | classes)]
[c.name/]
[/for]
[/let]
This one works fine, you will see the list of all class names.
Second script sample :
[let classes : Sequence(Class) =
pkg.ownedElement->filter(Class)->reject
(c : Class |
c.visibility <> VisibilityKind::public)]
[for (c : Class | classes)]
[c.name/]
[/for]
[/let]
Ouch, what's happening ? No more classes ?
Is that the reject condition which fails ?
Try this one :
[let classes : Sequence(Class) =
pkg.ownedElement->filter(Class)->reject
(c : Class | false)]
[for (c : Class | classes)]
[c.name/]
[/for]
[/let]
Same... no more class.
So is that the sole application of reject ?
Try this one :
[let classes : Sequence(Class) =
pkg.ownedElement->filter(Class)]
[for (c : Class | classes)]
[c.name/]
[/for]
[/let]
All classes back now.
Do not know why, reject seems to not work when it is applied to the result of "pkg.ownedElement->filter(Class)", while it works when it is applied to the result of "pkg.eAllContents(Class)"
[Updated on: Tue, 07 September 2010 16:43] Report message to a moderator |
|
|
| Re: [Acceleo 3] ownedElement + filter + reject : unexpected behavior [message #557536 is a reply to message #557488] |
Wed, 08 September 2010 02:22  |
|
Hi Yannick,
The problem is not coming from the filter or the reject it is coming from an invalid cast between the result of the reject and the type Sequence.
You can see in this picture that it works with a set but not with a sequence. Our documentation says that filter return a sequence, I'm pretty sure (with that problem) that it is returning a set instead or even better an OrderedSet (you should try with OrderedSet). So the documentation is false or our return type is false. I will check with the rest of the team to see which one is wrong. And we will correct that.
Stephane Begaudeau, Obeo
[Updated on: Wed, 08 September 2010 02:29] Report message to a moderator |
|
|
|
|
| Re: [Acceleo 3] ownedElement + filter + reject : unexpected behavior [message #557667 is a reply to message #557556] |
Wed, 08 September 2010 13:13 |
|
This is a multi-part message in MIME format.
--------------000604010806090603060605
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
Thanks for the link to the bugzilla Ed, didn't remember where this
discussion had been held :).
In summary :
With the Acceleo 3.0.0 build, "filter" always returned a Sequence, no
matter what the source type was. This is no longer the case on HEAD and
the fix will be present in the 3.1.0M2 build (though not in the 3.0.1
maintenance builds has it changes existing behavior).
What you have is "package.ownedElement->filter". UML has no "ordered"
properties IIRC (seems like UML doesn't like the idea of ordering
things); and thus you _cannot_ have a Sequence (or an OrderedSet for
that matter) as a result. You have either a Set or a Bag depending on
whether the ownedElement property accepts duplicates. Stéphane's test
seem to indicate it is a Set.
You have to give extra attention when using the MOFM2T "let" block which
behavior is _not_ the same as the plain OCL "let". Acceleo's "let" does
allow for the creation of variables ... but it cannot throw compilation
errors with the type of the init expression not corresponding to the
variable type : the specification mentions that Acceleo's "let" should
act as an "oclAsType" (or "instanceof" if you prefer Java terms).
Our documentation is wrong about the return type of the "filter"
operation, it has been fixed on HEAD and the return type will no longer
be documented as "Sequence(X)" in 3.1.0M2.
I believe these cover all of the confusion, let me know if I missed a
point :).
Laurent Goubet
Obeo
Ed Willink wrote:
> Hi
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=321011
>
> Regards
>
> Ed Willink
>
>
> On 08/09/2010 03:22, Stephane Begaudeau wrote:
>> Hi Yannick,
>>
>> The problem is not coming from the filter or the reject it is coming
>> from an invalid cast between the result of the reject and the type
>> Sequence.
>>
>>
>> You can see in this picture that it works with a set but not with a
>> sequence. Our documentation says that filter return a sequence, I'm
>> pretty sure (with that problem) that it is returning a set instead. So
>> the documentation is false or our return type is false. I will check
>> with the rest of the team to see which one is wrong. And we will correct
>> that.
>>
>> Stephane Begaudeau, Obeo
>
--------------000604010806090603060605
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------000604010806090603060605--
|
|
|
|
Powered by
FUDForum. Page generated in 0.03997 seconds
] 
Search
Help
Register
Login
Home
