Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <22551572.1178156355428.JavaMail.jira@brutus>
Date: Wed, 2 May 2007 18:39:15 -0700 (PDT)
From: "Stephen Kestle (JIRA)" <jira@apache.org>
To: commons-dev@jakarta.apache.org
Subject: [jira] Created: (COLLECTIONS-251) Replace getInstance() and
 decorate() methods with get{ClassName}()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org