[
https://issues.apache.org/jira/browse/GROOVY-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585454#comment-14585454
]
Peter Ledbrook commented on GROOVY-7464:
----------------------------------------
OK. That's sad because intersection has a specific meaning and behaviour in
maths that doesn't fit with the above. At this point, I think I'd rather
deprecate the method and leave it off {{CharSequence}} as it's current
semantics are confusing, or at least run against common expectation.
What sort of work are you thinking?
> Iterable.intersect() is not commutative (and allows duplicates)
> ---------------------------------------------------------------
>
> Key: GROOVY-7464
> URL: https://issues.apache.org/jira/browse/GROOVY-7464
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
> Affects Versions: 2.4.3
> Reporter: Peter Ledbrook
> Assignee: Guillaume Laforge
>
> The {{intersect()}} method on {{Iterable}} has different results depending on
> the order of the receiver object and the argument. For example,
> {code}
> def a = [1, 1, 2, 4]
> def b = [1, 2, 2, 3]
> println a.intersect(b)
> println b.intersect(a)
> {code}
> prints out two different results ({{[1, 1, 2]}} and {{[1, 2, 2]}}).
> Assuming that the operation should be commutative, i.e. the results should be
> the same for both, the question then becomes whether duplicates should even
> be returned at all.
> I think the method should always return a set as intersection is a set
> operation. In other words, {{Iterable.intersect()}} becomes a convenience
> wrapper that converts the receiver object and the argument to sets.
> This issue started as a discussion on the [dev mailing
> list|http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/browser].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
