Way back at the start of the debates, we had a choice between:
- CollectionUtils.transformedCollection()
- TransformedCollections.collection()
- Transformed.collection()
In the end we settled on the first, however I have on various occasions felt the latter would have been better.
This then got more confused by the break out into subpackages in v3.0. At that point, the 'best' way to create the class became:
- TransformedCollection.decorate()
however, we left the method on CollectionUtils for compatability.
Thus, there is an argument that says all the decoration methods on CollectionUtils (and similar classes) should be deprecated. However, personally I feel their use is now too widespread for this step.
Feel free to add more javadoc however, perhaps indicating the preferred way to create these classes.
Stephen
Rob Oxspring wrote:
Thanks James,
The latter scenario is exactly the one I keep finding myself in! I guess it's the naming that throws me - the collect() methods provide what I'd expect of transformedCollection() under a name that seems pretty abstract, whereas the implementation of transformedCollection() seem more suited to a method called transformingCollection(), although this could turn into a bike shed issue very quickly.
Seriously though, would it be reasonable to deprecate the collect() methods in favour of something with 'transform' in the name? I'm not sure what name to suggest but the word 'collect' might as well be dropped as all CollectionUtils methods are implicitly about collecting :)
In the meantime, thanks for the pointer to the collect() family of methods, I may well add some cross references in the javadocs between these and the transformedCollection() method to try and avoid future confusion.
Rob
James Carman wrote:
Are you wanting to add dates to the resulting collection and have them
transformed into Strings? Or, are you just looking for a collection of
Strings that you don't need to modify which represent the dates? If it's
the latter, you should use the CollectionUtils.collect() method rather than
the transformedCollection() method. I too have been burned by that very
thing. Just by looking at the name, it would seem that
transformedCollection() would return a collection which was the result of
applying the transformer to the input collection. Not so! I've learned
that the hard way a few times (bad memory).
-----Original Message-----
From: Rob Oxspring [mailto:[EMAIL PROTECTED] Sent: Saturday, May 07, 2005 11:42 AM
To: Jakarta Commons Developers List
Subject: [collections] TransformedCollection
Hi,
I've just been burnt (and not for the first time) by the fact that the TransformedCollection doesn't transform the objects that are already in the wrapped collection. For example:
Collection dates = ... // a collection with Date objects in it Transformer
toString = ... // a transformer that calls toString Collection strings =
CollectionUtils.transformedCollection(dates,toString);
My intuition tells me that strings should be full of String objects and have no Date objects in it but the opposite is true. Is this the intended behaviour or is this a bug? I'm happy to patch the TransformedCollection class but wanted to run it passed people first...
Thanks,
Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
