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