Enhancement request: implement Sets.transform(Set<F>, Function<? super F, ? extends T>)

[GoogleCodeExporter]

I like having Lists.transform(), it's a very nice functor for transforming
from one type to another.  However, there doesn't appear to be an
equivalent feature for transforming one set to another.

Seems like a natural transform to me.  

I've considered using Collections2.forIterable(Iterables.transform(set,
function)), but that seems like wasteful looping.

Thanks

Original issue reported on code.google.com by david.b...@gmail.com on 12 Nov 2008 at 4:42

[GoogleCodeExporter]

Our next snapshot will likely add Collections2.transform(), so you can view a 
Set (or
other Collection) transformed as a Collection.

But viewing a transformed Set as a Set requires that we trust your Function to 
be
injective.  If it isn't, you could get a badly-behaved Set out the other end. 
This is
a minefield that we don't currently view as worth the trouble. 

Thanks for your suggestion!

Original comment by kevin...@gmail.com on 12 Nov 2008 at 5:26

• Changed state: WontFix

[GoogleCodeExporter]

That is a pity, I need that too. I currently use this construct:

Function f = ...;
Set resultSet = Sets.newHashSet( Lists.transform( Lists.newArrayList( sourceSet 
), f ) );

Original comment by wim.debl...@gmail.com on 18 Mar 2009 at 10:18

[GoogleCodeExporter]

wouldn't

Sets.newHashSet(Iterables.transform(sourceSet, f));

be more practical then?

Original comment by jvdne...@gmail.com on 18 Mar 2009 at 1:31

[GoogleCodeExporter]

It would indeed. I did not know about Iterables.transform(). Thanks!

Original comment by wim.debl...@gmail.com on 18 Mar 2009 at 1:50

[GoogleCodeExporter]

What if the set returned by Sets.transform ensured it was well behaved by using 
a
special iterator that (while iterating) kept track of returned objects and 
skipped
any duplicates?

That way you could chain a bunch of filters and transforms on a set and return 
a set
without having to ever do a copy.

Just an idea.

Original comment by ada...@gmail.com on 19 Mar 2009 at 2:09

[GoogleCodeExporter]

With that approach, you'd still be making a copy, though that copy would be 
stored 
inside the iterator.

Original comment by jared.l....@gmail.com on 19 Mar 2009 at 4:25

[GoogleCodeExporter]

True! (although sometimes only partial copies)

I will stick to chaining on iterables and copying into a Set at the end.

Original comment by ada...@gmail.com on 19 Mar 2009 at 4:49

[GoogleCodeExporter]

Why not define an InjectiveFunction interface, so that it is possible to have:

Set<T> = Sets.transform(Set<S>, InjectiveFunction<S,T>)

InjectiveFunction would just extend the Function interface and not have any 
other
methods defined on it. The developer must then make a conscious decision to 
implement
InjectiveFunction, and should make sure that the implementation conforms to the
documentation in the interface.

Original comment by antonmar...@gmail.com on 20 Jan 2010 at 11:44