On 6 February 2013 11:24, Simone Tripodi <simonetrip...@apache.org> wrote: >> Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-)
One should never do that. Just use Boolean.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. But without looking carefully at the code, one cannot tell if FALSE is a local constant or Boolean.FALSE. I'd say that's an occasion when the static import is a bad idea. Although shorter, it's not as clear. It would be a really terrible idea to do a static import of Integer.MAX_VALUE. Imagine the fun trying to debug code which used: import static java.lang.Integer.MAX_VALUE; import static java.lang.Long.MIN_VALUE; That sort of code should be reserved for an obfuscation contest only. [BTW, import static requires the full package name] > -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
