[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512286
]
Stephen Kestle commented on COLLECTIONS-259:
--------------------------------------------
Presumably it's the decoration and continued implementation of Transformer in
the class that would be confusing. The constructor would be documented and
relatively invisible.
Don't know about others, but the way I learn about Collections (and other
utility frameworks) is by typing in my IDE. So I get to
TransformerClosure.decorate(Transformer) or new TransformerClosure(Transformer)
pretty quickly. The idea that it still implements Transformer would go
unnoticed, until such time as it is wanted, and then it would "appear".
I understand the concern, and like lots of ideas I have, it probably wants to
be mulled over. However isn't the entire usage of TransformerClosure a
"limited use case"?
> TransformerClosure should implement Transformer and allow extension.
> --------------------------------------------------------------------
>
> Key: COLLECTIONS-259
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
> Project: Commons Collections
> Issue Type: Improvement
> Components: Functor
> Affects Versions: 3.2
> Reporter: Stephen Kestle
> Priority: Minor
> Fix For: 3.3, Generics
>
>
> TransformerClosure currently decorates a transformer. However, in the
> interests of non-verbose code, it makes sense to be able to subclass it for a
> class that implements both interfaces.
> I propose the addition of the following constructor and method
> protected TransformerClosure(){
> iTransformer = this;
> }
> public O transform(I in){
> return iTransformer.transform();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
