On Mon, 16 Oct 2017 12:09:27 +0200, Benedikt Ritter wrote:
Hello Gilles,
Am 16.10.2017 um 11:07 schrieb Gilles
<gil...@harfang.homelinux.org>:
On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:
Am 16.10.2017 um 00:34 schrieb Gilles
<gil...@harfang.homelinux.org>:
On Sun, 15 Oct 2017 14:45:09 -0500, Matt Sicker wrote:
Assertion classes are just containers for static methods. Using
"import
static" is the only way in Java to import the individual methods
as if the
class itself were a package. Also, doing this is pretty common
when using
the Assert class as all its methods are prefixed with "assert"
anyways.
It's not because something is widespread that it should be
emulated.
Is there any good reason to use "import static"? [Saving the
typing
of 7 characters cannot be one of them.]
It can (and does) happen that "assert..." methods are defined
on a per project basis, and nothing is gained when the reader
has to check the top of the file to be sure of what class is
actually used.
My point was just that rather than cleaning up, the commit was
obfuscating (even if so little) the source code.
I prefer the other way around. :-)
I think there are pros and cons for both styles. I prefer static
imports. I don’t see any value in knowing, that assertEquals comes
from a class called Assert.
When you see "assertEquals", you cannot assume that it was
imported from the (Junit) "Assert" class.
In CM for example, another "assertEquals" is defined in an
internal "TestUtils" class.
With "static" import:
1. you won't readily know which class is used,
2. you can't use both classes (in the same way) within a
source file (and "first-class citizens" will vary from
project to project, and from file to file),
3. you can't easily make bulk changes (search and replace
e.g. following a library/API change).
I don't know which pros you are referring to, but having a
developer wondering, just once, about point (1) already
nullifies the supposed advantage I know of (less typing).
[It happened to me much more than once; thus, I remove
static imports whenever encountered…]
I think Matt and I have both pointed out, why this is irrelevant.
I think I had answered to the "common" argument before Matt
raised it.
As for the other argument: a basic tenet of OO languages (as
Java purports to be, last time I checked) is that you should
not assume you know the internals of a class (hence "it
contains only static methods" can be falsified at some future
point in time).
So
I don’t see a reason to start yet another endless discussion.
Dismissing others' experience (with the disadvantages cited
above) as being irrelevant is not a discussion.
The subject line of this thread is not a consensus.
Let's leave it at that.
Gilles
Benedikt
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
