[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538959
]
Stephen Kestle commented on COLLECTIONS-251:
--------------------------------------------
I don't think so :)
BTW, this ticket was raised as a replacement for the current *Utils way of
doing it for the reasons above, not because they dont exist.
1. We promote a better static constructor pattern to the community.
2. Functors is likely to be split from collections
3. It makes more sense to find a class and use it rather than a compilation
4. These should not be in a *Utils class, but rather *s e.g. Predicates rather
than PredicateUtils
5. Java cannot attach new functions to an existing class (and extension is
difficult).
6. Do *Utils have (classes x no of instantiators) number of methods for this?
7. If so, maintenance is more difficult, and inconsistencies arise
8. These inconsistencies are made more difficult with generics, as
modifications are likely.
9. See points 2-end of the ticket.
The generics collection is meant to be a rewrite and re-evaluation.
Superfluous code that increases coding time and maintenance, in the face of a
(IMHO) more elegant solution should be eliminated in this release (the
final-clean-non deprecated version).
> 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.
