You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Matt Benson (JIRA)" <ji...@apache.org> on 2011/07/20 16:48:58 UTC
[jira] [Updated] (COLLECTIONS-251) improving static factory methods
for static importability, conistency
[ https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Benson updated COLLECTIONS-251:
------------------------------------
Summary: improving static factory methods for static importability, conistency (was: Replace getInstance() and decorate() methods with get{ClassName}())
> improving static factory methods for static importability, conistency
> ---------------------------------------------------------------------
>
> 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: 3.2
> Reporter: Stephen Kestle
> Fix For: 4.0-beta-1
>
>
> 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:
> 1. 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.
> 2. 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).
> 2.1 Overridden and overloaded static methods are a really bad idea
> 2.2 No confusion about what class is being instantiated
> 2.3 As our methods become more useful in the generic sense, the compiler issues increase until you hit something that just won't work
> 3. Simple migration path - those using TruePredicate.getInstance() can switch to PredicateUtils.truePredicate() before updating to this version.
> 4. 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira