> 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.
-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
