commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [collections] TransformedCollection
Date Sun, 08 May 2005 21:42:32 GMT
Really the problem is that the method transformedCollection() got added 
to CollectionUtils at all.

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:roxspring@imapmail.org] 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message