commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <>
Subject Re: [collections] VOTE: Collections-java5 direction
Date Mon, 12 Mar 2007 19:41:47 GMT
James Carman wrote:
> I +1 all the same stuff, but I'd recommend removing all the 
> getInstance() methods and just provide access via the "*Utils" classes.  
I guess, since it's there... but if you were to make a new Predicate of 
some sort, would you want to update a utility class as well?  Java 
already has a mechanism for getting objects of a certain type - the 
class itself.  Do we really need to catalogue them?  Ideally, I'd like 
to see the *Utils classes as utilities rather than object getters.  So 
I'd deprecate those methods (or follow whatever incompatibility 
migration procedure we come up with).
I appreciate that that's a change, but again, I want to ensure 
everything is right rather than pulling through heaps of legacy stuff.  
I'm not sure which way I'd go on this one...
> If someone's dumb enough to instantiate a TruePredicate object 
> directly, let them (why do we need to be so heavyhanded).  
Because construction implementation changes - classes get split and 
combined.  While it's not likely to change here anymore, I feel it's a 
valuable process to pass on to developers.  I think very carefully about 
whether I want to give out a constructor in case it doesn't work very 
well in the future (remember, any this() or super() calls have to be 
first, the getInstance() methods can work around this).

Under generics it becomes even more important.  The getInstance() method 
is able to infer the generic types needed under many instances.  So 
instead of:
Predicate<MyObject> p = new TruePredicate<MyObject>();
you end up with
Predicate<MyObject> p = getTruePredicate();  //or getInstance() - ick
(after static import).

It's also important for converting singletons to individual instances 
(perhaps thread safety or something).  Again, not likely to happen here, 
but good none the less.  We don't know that one little thing we'll want 
to change, so we apply it everywhere.
> It's pretty lightweight anyway.  Otherwise, they can use 
> PredicateUtils.getTruePredicate().
Fine for TruePredicate, but look at the Maps etc - each one has 3 
construction mechanisms from memory.  I don't want a Utils method explosion.

Apologies for the length


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message