commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java
Date Wed, 06 Feb 2013 09:16:02 GMT
2013/2/5 Benedikt Ritter <britter@apache.org>

> Hi Simo,
>
>
> 2013/2/5 Simone Tripodi <simonetripodi@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message