There should be an easy way of doing a one-off transformed collection

[GoogleCodeExporter]

I have a Function that makes a new object (for further editing) from an 
existing object. (e.g. B transform(A a) { return new B(a);})

When I use Collections.transform() or Lists.transform() this applies the 
Function as a view on the given collection.  However, I want to have a 
collection of objects that are disjoint from the original (so that my edits 
will be kept, instead of losing them as soon as the scope is lost).

* This behaviour is troublesome for those coming from commons-collections
* Commons-collections had a third parameter for the collection to populate 
with the transformed items
* Perhaps this would be a case for having a NonDeterministicFunction 
interface to mark that the function result should be saved rather than re-
executed.  This would be especially helpful for me, as I am providing the 
function class, and it could afford itself to be used correctly.
* I understand that I can copy the collection into a new one, but it's 
another step for others to learn to have to do.  (the transform() method 
indicates a one-off action - I would have called it transformedView() to 
make it's operation explcit)

Original issue reported on code.google.com by step...@kestle.homeip.net on 3 Jun 2009 at 10:51

[GoogleCodeExporter]

Oh - 1.0.0.rc1

Original comment by step...@kestle.homeip.net on 3 Jun 2009 at 10:51

[GoogleCodeExporter]

...also, wrapping it in a new collection increases my line length by around 30 
chars 
by the time I put generics in - not nice :(

Original comment by step...@kestle.homeip.net on 3 Jun 2009 at 10:52

[GoogleCodeExporter]

We have always viewed passing the result of transform() to a copy method like
ImmutableList.copyOf() or Lists.newArrayList() as a perfectly fine solution.  
Our
APIs are meant to give you the building blocks to do many things, but we don't
promise that it will always come out terse.

I understand your point about "transformedView", and we once did consider 
adding this
suffix, which would have meant changing a very large number of methods 
throughout our
API.  We didn't like the results, and decided against it.

Original comment by kevin...@gmail.com on 3 Jun 2009 at 11:05

• Changed state: WontFix