Bug 465895 - intersection(Sequence) is exposed yet not implemented
Summary: intersection(Sequence) is exposed yet not implemented
Status: RESOLVED FIXED
Alias: None
Product: Acceleo
Classification: Modeling
Component: Query Language (show other bugs)
Version: 3.6.0   Edit
Hardware: PC Linux
: P3 normal
Target Milestone: RC1   Edit
Assignee: Yvan Lussaud CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-30 04:53 EDT by Cedric Brun CLA
Modified: 2015-06-08 05:36 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric Brun CLA 2015-04-30 04:53:17 EDT 
We should either make sure that this is implemented or not expose it in the code assist and validation.

Right now :
aql:self->asSequence()->intersection(self->asSequence())

returns nothing.

in MTL 
self->asSequence()->intersection() does not exit

on the other hand :
self->asBag()->intersection(Bag other) exists.

"Bag" is "a non ordered List", as such might contains dupplicates.

We should implement intersection(List/List) in MTL with the same behavior as MTL's intersection on Bags in order to ease the migration path.
Comment 1 Cedric Brun CLA 2015-04-30 05:18:08 EDT 
It looks like the MTL version is implemented here:

org.eclipse.ocl.util.CollectionUtil.intersection(Collection<? extends E>, Collection<? extends E>)

in particular :
   // loop over the smaller collection and add only elements
        // that are in the larger collection
        if (self.size() > c.size()) {
            for (E e : c) {
                if (includes(self, e)) {
                    result.add(e);
                }
            }
        } else {
            for (E e : self) {
                if (includes(c, e)) {
                    result.add(e);
                }
            }
        }


which is "ok" from a specification point of view but is not conform to what we want to achieve : the order of the result might vary depending on whether the first list has more elements than the second. *We want an order which, even if it's not defined explicitely, is predictable and constant whatever the input model is*. The principle of least surprise. Implementing it with a List.retainAll() calls seems like the way to go, order is kept, dupplicates in the first operand are kept but removed if are in the second operand.
Comment 2 Laurent Goubet CLA 2015-05-12 05:13:57 EDT 
Review https://git.eclipse.org/r/47599 submitted to introduce "intersection" on Lists, and allow intersections between lists and sets (or the reverse).
Comment 3 Cedric Brun CLA 2015-05-13 10:08:59 EDT 
merged and fixed for RC1
Comment 4 Yvan Lussaud CLA 2015-05-20 10:45:17 EDT 
The validation of the intersection service should be implemented. Some ideas:

- remove types with no common ancestor between the two collections
- add both types if common ancestor
Comment 5 Yvan Lussaud CLA 2015-05-20 10:54:31 EDT 
for validation add the lowest common ancestor instead of both types
Comment 6 Eclipse Genie CLA 2015-05-28 11:08:17 EDT 
New Gerrit change created: https://git.eclipse.org/r/48880
Comment 8 Yvan Lussaud CLA 2015-06-08 05:36:20 EDT 
Tests has been added and a little fix has been made on the validation.