[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538730 ]

Brian Egge commented on COLLECTIONS-251:
----------------------------------------

It appears these methods exist in the current PredicateUtils class.  I don't see any need to depreciate the getInstance methods.  Can this JIRA be closed?

> Replace getInstance() and decorate() methods with get{ClassName}()
> ------------------------------------------------------------------
>
>                 Key: COLLECTIONS-251
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
>             Project: Commons Collections
>          Issue Type: Improvement
>          Components: Bag, BidiMap, Buffer, Collection, Comparator, Core, Functor, Iterator, KeyValue, List, Map, Set
>    Affects Versions: Generics
>            Reporter: Stephen Kestle
>             Fix For: Generics
>
>
> Commons Collections uses the singleton "getInstance()" pattern and extends it to allow parameters etc to be passed in.  decorate() serves a similar purpose.
> I propose replacing both of these with getClassName() for the following reasons:
> # Static imports would mean that TruePredicate.getInstance() would be replaced with getTruePredicate().  getInstance() cannot be statically imported, because it is reduced to one class' getInstance(), where we are likely using many.
> # It gives subclasses a way to avoid compiler issues - COLLECTIONS-243 compile problems are generally because the compiler can't choose between Collection<T> and Set<T>.  Doing this change completely avoids this issue - even if there is a workaround, this makes life a lot easier (different compilers - eclipse - will allow things that the Sun one won't).  
> ## Overridden and overloaded static methods are a really bad idea
> ## No confusion about what class is being instantiated
> ## As our methods become more useful in the generic sense, the compiler issues increase until you hit something that just won't work
> # Simple migration path - those using TruePredicate.getInstance() can switch to PredicateUtils.truePredicate() before updating to this version.
> # Allows a more consistent user environment.  Following the current pattern means that most people will have MyTransformer.getInstance(), while using TransformerUtils.nopTransformer().
> Our work will be made a lot easier if we make this change.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.