commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java
Date Wed, 06 Feb 2013 19:35:59 GMT
On 6 February 2013 11:24, Simone Tripodi <simonetripodi@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 <britter@apache.org> wrote:
>> 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
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message