2013/2/5 Benedikt Ritter <brit...@apache.org> > Hi Simo, > > > 2013/2/5 Simone Tripodi <simonetrip...@apache.org> > >> 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. >> > > As I said, I haven't decided yet how to handle static imports. > You're right, when pointing out, that not using static imports here is > more verbose. But IMHO BU2 is a step forward compared to BU1 even without > static imports! :) > > I personally would probably do something like: > BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with( argument( > Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-) >
In fact the valueOf() factory methods in the wrapper types a a good example of where not to use static imports. WDYT? > > This way I can see what API I'm entering. For the call to > Argument.argument(T) I would use a static import, because it is clear what > context it is coming from. In fact, this is, how I use EasyMock at work. I > qualify calls to expect(), replay(), verify() etc but use static import > when using the factory methods for IExpectationSetters. > > Makes sense? Probably only to me :) See, it's just a convention I've found > useful for myself. > > >> >> > 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? >> > > Your right. I'd normally try to import java.util.List, because it is the > most common List implementation and qualify java.awt.List if I have to use > both in the same class. But again this is only a convention I have made for > myself. > > >> >> > 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. >> > > I guess I'll just revert that commit and we'll see were it gets us. > Thanks for sharing your thoughts! > > Benedikt > > >> >> 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 >> >> >
