2013/2/6 Simone Tripodi <simonetrip...@apache.org> > > Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-) > > or just > > import static Boolean.FALSE > > then > > on( testBean ).invoke( "setBooleanProperty" ).with( argument( FALSE ) > ); > > which is less verbose and avoids the potential naming conflict. >
That's true for Boolean. But what will by returned by valueOf( (short) 4 ) );? It can be a Short object, as well as an Integer. At least give me that one :) Benedikt > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > On Wed, Feb 6, 2013 at 10:16 AM, Benedikt Ritter <brit...@apache.org> > wrote: > > 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 > >>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
