Static Imports

[Brock Noland <br...@cloudera.com>]

Static imports should always be used conservatively. However, there a
few classes that static imports make for a much more fluent style and
is a generally accepted practice:

1) Mockito
2) JUnit Assert
3) Guava Preconditions

I have noticed that Flume does not use static imports but nothing is
mentioned on the wiki. Are we against static imports in the cases
above?

Brock

-- 
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: Static Imports

[Brock Noland <br...@cloudera.com>]

Thanks Eric for you reply. I agree in general with you statements,
which is why it's a good practice to use it sparingly. I don't like
seeing it outside of the three items I presented originally.

Everyone seems to be writing patches using a qualified name for Assert
and Guava Preconditions. I can live with that.  However, Mockito
syntax really suffers without a static import. If we decided against
static imports as a whole, I would like to see exception for Mockito.

Brock

On Mon, Feb 27, 2012 at 12:41 PM, Eric Sammer <es...@cloudera.com> wrote:
> They drive me bananas and since I wrote a bunch of the original code, that
> probably accounts for the lack of static imports. There's no rule against
> them because, while I don't like them, I get that they're not overtly
> harmful.
>
> My (arguably flawed) dislike of them is because:
>
> * I think it's clearer to see the name of the class static methods come
> from for documentation purposes.
> * It makes autocompletion in IDEs saner.
> * It future proofs against the creation of similarly named methods within
> the inheritance hierarchy.
> * It creates consistency across the codebase.
> * It provides no meaningful value (in my opinion) - I personally *always*
> prefer fewer alterations[1] to the normal language behavior to reduced
> typing.
>
> [1] Static imports effectively fly in the face of what we're taught about
> unqualified method invocation; that they're within the inheritance tree. It
> forces you to think of something different (some of the same issues with
> multiple inheritance).
>
> I would ask that we go one direction or another, though; I don't want to
> have to guess (or start looking at the import list) when I read the code.
> Of course, we're not going to statically import every static method so...
> (you see my personal dilemma)
>
> On Sat, Feb 25, 2012 at 10:30 PM, Brock Noland <br...@cloudera.com> wrote:
>
>> Static imports should always be used conservatively. However, there a
>> few classes that static imports make for a much more fluent style and
>> is a generally accepted practice:
>>
>> 1) Mockito
>> 2) JUnit Assert
>> 3) Guava Preconditions
>>
>> I have noticed that Flume does not use static imports but nothing is
>> mentioned on the wiki. Are we against static imports in the cases
>> above?
>>
>> Brock
>>
>> --
>> Apache MRUnit - Unit testing MapReduce -
>> http://incubator.apache.org/mrunit/
>>
>
>
>
> --
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com



-- 
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: Static Imports

[Eric Sammer <es...@cloudera.com>]

They drive me bananas and since I wrote a bunch of the original code, that
probably accounts for the lack of static imports. There's no rule against
them because, while I don't like them, I get that they're not overtly
harmful.

My (arguably flawed) dislike of them is because:

* I think it's clearer to see the name of the class static methods come
from for documentation purposes.
* It makes autocompletion in IDEs saner.
* It future proofs against the creation of similarly named methods within
the inheritance hierarchy.
* It creates consistency across the codebase.
* It provides no meaningful value (in my opinion) - I personally *always*
prefer fewer alterations[1] to the normal language behavior to reduced
typing.

[1] Static imports effectively fly in the face of what we're taught about
unqualified method invocation; that they're within the inheritance tree. It
forces you to think of something different (some of the same issues with
multiple inheritance).

I would ask that we go one direction or another, though; I don't want to
have to guess (or start looking at the import list) when I read the code.
Of course, we're not going to statically import every static method so...
(you see my personal dilemma)

On Sat, Feb 25, 2012 at 10:30 PM, Brock Noland <br...@cloudera.com> wrote:

> Static imports should always be used conservatively. However, there a
> few classes that static imports make for a much more fluent style and
> is a generally accepted practice:
>
> 1) Mockito
> 2) JUnit Assert
> 3) Guava Preconditions
>
> I have noticed that Flume does not use static imports but nothing is
> mentioned on the wiki. Are we against static imports in the cases
> above?
>
> Brock
>
> --
> Apache MRUnit - Unit testing MapReduce -
> http://incubator.apache.org/mrunit/
>



-- 
Eric Sammer
twitter: esammer
data: www.cloudera.com