[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997719#comment-12997719
]
Stephen Colebourne commented on COLLECTIONS-251:
------------------------------------------------
For the record, JSR-310 now uses 'of' prefix on classes:
LocalDate.of(2011, 6, 12);
OffsetDateTime.ofInstant(instant);
and short names on utility classes:
DateAdjusters.lastDayOfMonth();
There is a plan to then add a separate "static imports" utility class, which
remaps names like "of" to "date". That class may not be in the core of JSR-310.
The short names like truePredicate() look reasonable here.
> 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: 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
