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

Reply via email to