commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [collections] TransformedCollection
Date Mon, 09 May 2005 11:42:30 GMT
Does collections have a defined deprecation policy? I.e. have we made a 
promise as to when they are to be deleted, were we to deprecate the 
decoration methods in *Utils classes?  The way I see it, the wide spread 
argument provides a good reason not to delete the methods in a hurry but 
shouldn't stop us from using deprecation to recommend the 'correct' way 
forward.

Rob

Stephen Colebourne wrote:
> 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
> 

---------------------------------------------------------------------
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