commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lambrou <m...@chrislambrou.com>
Subject Re: [collections] InvokerClosure
Date Thu, 02 Dec 2004 23:40:48 GMT
  Eric Pugh wrote:

> Is the final result:
>
> CollectionUtils.forAllDo(configList, new InvokerClosure("clearProperty",
> String.class, key));
>
> Compared to the original really that much cleaner?:
> for (Iterator i = configList.iterator(); i.hasNext();)
> {
> Configuration config = (Configuration) i.next();
> config.clearProperty(key);
> }
>
Not really. I think that there are two separate issues here. The first 
is general usefulness of the InvokerClosure class. The second is the 
usefullnes of the CollectionUtils.forAllDo() method.

For the InvokerClosure, I can think of a couple of situations where it 
might prove useful. The first is in some sort of scripting environment, 
where the method name and/or arguments are not known at compile time. 
The second is when you are executing the closure over a collection in a 
situation where the elements don't implement a single common interface, 
but are known to share a particular method signature (to be honest, I'm 
finding it hard to think of such a real world example). In Emmanuel's 
example, neither of these cases apply, so the resulting code doesn't 
really add much clarity.

For the CollectionUtils.forAllDo() method, whilst it improves the 
compactness of the code alternatives it replaces, it's perhaps a bit too 
unfamiliar looking to yield a corresponding improvement in clarity.

I just think that Emmanuel has found an example that combines the 
unnecessary use of the InvokerClosure and the questionable improvement 
in clarity of the CollectionUtils.forAllDo() method to produce some code 
that doesn't really improve on the code it has replaced.


Chris

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


Mime
View raw message