[ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

Benedikt Ritter-4
Hi,

we had a little discussion in BeanUtils2, regarding static imports (see
below). To increase visibility and get some more feedback, I'm forwarding
this to [ALL]

We haven't decided yet how to handle static imports. To form some rules,
we'd like to hear what others think about static imports and what rules of
thumb you use in your projects.

I'm exited to hear your opinions :)
Regards,
Benedikt


2013/2/4 Jörg Schaible <[hidden email]>

> Hi,
>
> Benedikt Ritter wrote:
>
> > Hi Simo,
> >
> > thanks for sharing your thoughts! I personally try to avoid static
> > imports. Especially when you come to a legacy code base IMHO it makes the
> > code harder to understand. You always have to look, where a method comes
> > from.
>
> Actually I avoid static imports for the same reason.
>
> > Also you may have the problem, that you accidentally override
> > imported static methods, when defining a new static method with the same
> > name. BU2 is a very small code base, so it would be okay for me to revert
> > the change.
> >
> > Nevertheless I'd be interested to hear what others thing about this
> topic.
>
> my 2¢
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

garydgregory
On Mon, Feb 4, 2013 at 4:32 PM, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
> we had a little discussion in BeanUtils2, regarding static imports (see
> below). To increase visibility and get some more feedback, I'm forwarding
> this to [ALL]
>
> We haven't decided yet how to handle static imports. To form some rules,
> we'd like to hear what others think about static imports and what rules of
> thumb you use in your projects.
>
> I'm exited to hear your opinions :)
>

I do not use static imports at work. I do not like using them unless it is
for math like expressions (with PI and the like).

Gary


> Regards,
> Benedikt
>
>
> 2013/2/4 Jörg Schaible <[hidden email]>
>
> > Hi,
> >
> > Benedikt Ritter wrote:
> >
> > > Hi Simo,
> > >
> > > thanks for sharing your thoughts! I personally try to avoid static
> > > imports. Especially when you come to a legacy code base IMHO it makes
> the
> > > code harder to understand. You always have to look, where a method
> comes
> > > from.
> >
> > Actually I avoid static imports for the same reason.
> >
> > > Also you may have the problem, that you accidentally override
> > > imported static methods, when defining a new static method with the
> same
> > > name. BU2 is a very small code base, so it would be okay for me to
> revert
> > > the change.
> > >
> > > Nevertheless I'd be interested to hear what others thing about this
> > topic.
> >
> > my 2¢
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
E-Mail: [hidden email] | [hidden email]
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

Ted Dunning
Another common use is with junit to import assertEquals and such.

On Mon, Feb 4, 2013 at 4:41 PM, Gary Gregory <[hidden email]> wrote:

> On Mon, Feb 4, 2013 at 4:32 PM, Benedikt Ritter <[hidden email]>
> wrote:
>
> > ...
> > We haven't decided yet how to handle static imports. To form some rules,
> > we'd like to hear what others think about static imports and what rules
> of
> > thumb you use in your projects.
>
> I do not use static imports at work. I do not like using them unless it is
> for math like expressions (with PI and the like).
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

Matt Benson-2
I would say that in general the Commons libraries favor *creating* APIs
such that intent reads most fluently by *not* using static imports.  I
would venture to say that given the examples of when static imports might
be desirable, a good rule of thumb wrt *use* of static imports would again
be "which way does intent read most fluently?"

Using this approach, the answer would be:  it depends on the library
defining the static member.

Matt


On Mon, Feb 4, 2013 at 7:34 PM, Ted Dunning <[hidden email]> wrote:

> Another common use is with junit to import assertEquals and such.
>
> On Mon, Feb 4, 2013 at 4:41 PM, Gary Gregory <[hidden email]>
> wrote:
>
> > On Mon, Feb 4, 2013 at 4:32 PM, Benedikt Ritter <[hidden email]>
> > wrote:
> >
> > > ...
> > > We haven't decided yet how to handle static imports. To form some
> rules,
> > > we'd like to hear what others think about static imports and what rules
> > of
> > > thumb you use in your projects.
> >
> > I do not use static imports at work. I do not like using them unless it
> is
> > for math like expressions (with PI and the like).
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

Benedikt Ritter-4
In reply to this post by Benedikt Ritter-4
Hey,

thanks for your feedback. It's interesting to see that there seem to be two
opposing opinions:
Some try to avoid static imports as much as possible, while others use them
if it makes the code "more fluent".

I found the Matt's comment especially useful, for pointing out, that we (as
developers of o.a.commons) have have to views/roles.
On the one hand we are creators of APIs that should read fluently without
having to use static imports extensively.
On the other hand we are developers who have to decide how we want to use
static imports internally.

I think that's the core of my question. Do we have any kind of guideline
regarding the use of static imports in commons library code?

Regards,
Benedikt


2013/2/5 Matt Benson <[hidden email]>

> I would say that in general the Commons libraries favor *creating* APIs
> such that intent reads most fluently by *not* using static imports.  I
> would venture to say that given the examples of when static imports might
> be desirable, a good rule of thumb wrt *use* of static imports would again
> be "which way does intent read most fluently?"
>
> Using this approach, the answer would be:  it depends on the library
> defining the static member.
>
> Matt
>
>
> On Mon, Feb 4, 2013 at 7:34 PM, Ted Dunning <[hidden email]> wrote:
>
> > Another common use is with junit to import assertEquals and such.
> >
> > On Mon, Feb 4, 2013 at 4:41 PM, Gary Gregory <[hidden email]>
> > wrote:
> >
> > > On Mon, Feb 4, 2013 at 4:32 PM, Benedikt Ritter <[hidden email]>
> > > wrote:
> > >
> > > > ...
> > > > We haven't decided yet how to handle static imports. To form some
> > rules,
> > > > we'd like to hear what others think about static imports and what
> rules
> > > of
> > > > thumb you use in your projects.
> > >
> > > I do not use static imports at work. I do not like using them unless it
> > is
> > > for math like expressions (with PI and the like).
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

jodastephen
In reply to this post by Benedikt Ritter-4
FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.

Stephen


On 4 February 2013 21:32, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
> we had a little discussion in BeanUtils2, regarding static imports (see
> below). To increase visibility and get some more feedback, I'm forwarding
> this to [ALL]
>
> We haven't decided yet how to handle static imports. To form some rules,
> we'd like to hear what others think about static imports and what rules of
> thumb you use in your projects.
>
> I'm exited to hear your opinions :)
> Regards,
> Benedikt
>
>
> 2013/2/4 Jörg Schaible <[hidden email]>
>
>> Hi,
>>
>> Benedikt Ritter wrote:
>>
>> > Hi Simo,
>> >
>> > thanks for sharing your thoughts! I personally try to avoid static
>> > imports. Especially when you come to a legacy code base IMHO it makes the
>> > code harder to understand. You always have to look, where a method comes
>> > from.
>>
>> Actually I avoid static imports for the same reason.
>>
>> > Also you may have the problem, that you accidentally override
>> > imported static methods, when defining a new static method with the same
>> > name. BU2 is a very small code base, so it would be okay for me to revert
>> > the change.
>> >
>> > Nevertheless I'd be interested to hear what others thing about this
>> topic.
>>
>> my 2¢
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]