Guten Tag, Bene,
> I personally try to avoid static imports.
> Especially when you come to a legacy code base IMHO it makes the code
> harder to understand.
as BU2 user, would you write the following sentence
on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
Boolean( false ) ) );
as
BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with(
Argument.argument( new Boolean( false ) ) );
?
Better switching back to old BU APIs, there's no benefit anymore on
switching to a functional-style approach APIs.
> You always have to look, where a method comes from.
Isn't the same thing we have to do with classes? when using a List,
what ensures you are using java.util.List rather than java.awt.List?
Why you consider methods case so different to classes?
> Also you may have the problem, that you accidentally override imported
> static methods, when defining a new static method with the same name.
same name, same arguments and same return type? It would be possible.
But, again, that would be possible doing it also with classes, same
package and same name; as exercise, create a project and import
commons-beanutils-1.7.0 + commons-collections-3.2.1: which version of
FastHashMap is taken by the classloader?
I still haven't found the reason why methods should be a special case.
What I am sure, there's no rule.
my 0.00000002 though,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
