commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
Date Tue, 22 Feb 2011 10:08:38 GMT

    [ 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

        

Mime
View raw message