I agree that contains() of HashSet is more efficient than the one of LinkedList and ArrayList. But unfortunately it has the negative side effect of preventing the presence of multiple equal items in the same collection. Although multi-occurrence is not yet properly implemented, that's something I want the library to fully support someday. So I don't think a generic utility function like filteredCopyOf should make any limiting assumptions about the nature of the collections it is applied to.

If this really takes a big hit on the performance, I could imagine some kind of type checking to properly adapt to Set and List types and choose an appropriate implementation. But even this adds some complexity I'd like to avoid.

Come to think of it, I think that sooner or later there should be special Differ implementations for HashSet, TreeSet, LinkedList, etc., which can properly cater to the special characteristics of the underlying collection types. This would render the collection utilities more or less obsolete (or at least use them in a less generic way.)

So for now I would rather not merge this pull request. Sorry. I hope that's okay for you. If this takes a huge performance hit in your use-case, let me know. Maybe we are able to find some other ways to speed it up.

Sure i am open to discussion and indeed your are right concerning the
negative side effect. I will also rollback my changes :)

2014年10月29日 23:59 GMT+01:00 Daniel Bechler notifications@github.com:

I agree that contains() of HashSet is more efficient than the one of
LinkedList and ArrayList. But unfortunately it has the negative side
effect of preventing the presence of multiple equal items in the same
collection. Although multi-occurrence is not yet properly implemented,
that's something I want the library to fully support someday. So I don't
think a generic utility function like filteredCopyOf should make any
limiting assumptions about the nature of the collections it is applied to.

If this really takes a big hit on the performance, I could imagine some
kind of type checking to properly adapt to Set and List types and choose
an appropriate implementation. But even this adds some complexity I'd like
to avoid.

Come to think of it, I think that sooner or later there should be special
Differ implementations for HashSet, TreeSet, LinkedList, etc., which can
properly cater to the special characteristics of the underlying collection
types. This would render the collection utilities more or less obsolete (or
at least use them in a less generic way.)

So for now I would rather not merge this pull request. Sorry. I hope
that's okay for you. If this takes a huge performance hit in your use-case,
let me know. Maybe we are able to find some other ways to speed it up.

—
Reply to this email directly or view it on GitHub
#114 (comment)
.