Re: [text] always use static imports for assertion methods

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

Re: [text] always use static imports for assertion methods

Gilles Sadowski
On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
wrote:
> Repository: commons-text
> Updated Branches:
>   refs/heads/master 51645b4f0 -> 8f7d0494d
>
>
> always use static imports for assertion methods
>

Why?

Gilles

>
> [...]


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Pascal Schumacher
Just for consistency. All almost all tests already used static imports,
so I adjusted the few that did not.

-Pascal

Am 15.10.2017 um 11:44 schrieb Gilles:

> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
> wrote:
>> Repository: commons-text
>> Updated Branches:
>>   refs/heads/master 51645b4f0 -> 8f7d0494d
>>
>>
>> always use static imports for assertion methods
>>
>
> Why?
>
> Gilles
>
>>
>> [...]
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Gilles Sadowski
On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
> Just for consistency.

Consistency is fine. ;-)

> All almost all tests already used static
> imports, so I adjusted the few that did not.

It's the use of "import static" which I was questioning.

Gilles

>
> -Pascal
>
> Am 15.10.2017 um 11:44 schrieb Gilles:
>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC),
>> [hidden email] wrote:
>>> Repository: commons-text
>>> Updated Branches:
>>>   refs/heads/master 51645b4f0 -> 8f7d0494d
>>>
>>>
>>> always use static imports for assertion methods
>>>
>>
>> Why?
>>
>> Gilles
>>
>>>
>>> [...]
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Matt Sicker
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.

On 15 October 2017 at 13:44, Gilles <[hidden email]> wrote:

> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>
>> Just for consistency.
>>
>
> Consistency is fine. ;-)
>
> All almost all tests already used static
>> imports, so I adjusted the few that did not.
>>
>
> It's the use of "import static" which I was questioning.
>
> Gilles
>
>
>
>> -Pascal
>>
>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>
>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
>>> wrote:
>>>
>>>> Repository: commons-text
>>>> Updated Branches:
>>>>   refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>
>>>>
>>>> always use static imports for assertion methods
>>>>
>>>>
>>> Why?
>>>
>>> Gilles
>>>
>>>
>>>> [...]
>>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Gilles Sadowski
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. :-)

YMMV,
Gilles


> On 15 October 2017 at 13:44, Gilles <[hidden email]>
> wrote:
>
>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>
>>> Just for consistency.
>>>
>>
>> Consistency is fine. ;-)
>>
>> All almost all tests already used static
>>> imports, so I adjusted the few that did not.
>>>
>>
>> It's the use of "import static" which I was questioning.
>>
>> Gilles
>>
>>
>>
>>> -Pascal
>>>
>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>
>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC),
>>>> [hidden email]
>>>> wrote:
>>>>
>>>>> Repository: commons-text
>>>>> Updated Branches:
>>>>>   refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>
>>>>>
>>>>> always use static imports for assertion methods
>>>>>
>>>>>
>>>> Why?
>>>>
>>>> Gilles
>>>>
>>>>
>>>>> [...]
>>>>>
>>>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Benedikt Ritter-4


> Am 16.10.2017 um 00:34 schrieb Gilles <[hidden email]>:
>
> 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.

Cheers,
Benedikt

>
> YMMV,
> Gilles
>
>
>> On 15 October 2017 at 13:44, Gilles <[hidden email]> wrote:
>>
>>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>>
>>>> Just for consistency.
>>>>
>>>
>>> Consistency is fine. ;-)
>>>
>>> All almost all tests already used static
>>>> imports, so I adjusted the few that did not.
>>>>
>>>
>>> It's the use of "import static" which I was questioning.
>>>
>>> Gilles
>>>
>>>
>>>
>>>> -Pascal
>>>>
>>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>>
>>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
>>>>> wrote:
>>>>>
>>>>>> Repository: commons-text
>>>>>> Updated Branches:
>>>>>>  refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>>
>>>>>>
>>>>>> always use static imports for assertion methods
>>>>>>
>>>>>>
>>>>> Why?
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>> [...]
>>>>>>
>>>>>
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Gilles Sadowski
On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:

>> Am 16.10.2017 um 00:34 schrieb Gilles
>> <[hidden email]>:
>>
>> 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...]

Gilles

> Cheers,
> Benedikt
>
>>
>> YMMV,
>> Gilles
>>
>>
>>> On 15 October 2017 at 13:44, Gilles <[hidden email]>
>>> wrote:
>>>
>>>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>>>
>>>>> Just for consistency.
>>>>>
>>>>
>>>> Consistency is fine. ;-)
>>>>
>>>> All almost all tests already used static
>>>>> imports, so I adjusted the few that did not.
>>>>>
>>>>
>>>> It's the use of "import static" which I was questioning.
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>>> -Pascal
>>>>>
>>>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>>>
>>>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC),
>>>>>> [hidden email]
>>>>>> wrote:
>>>>>>
>>>>>>> Repository: commons-text
>>>>>>> Updated Branches:
>>>>>>>  refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>>>
>>>>>>>
>>>>>>> always use static imports for assertion methods
>>>>>>>
>>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Bruno P. Kinoshita-3
>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.

But the internal class could be named Assert. In that case you still wouldn't know if it was imported from JUnit until you looked at the import statements.

Said that, I don't use that argument to decide on static imports or not. I do use static imports most of the times. And my main reason is Eclipse import favourites. I have a few favourites [1] configured, including JUnit Assert class.

That way, whenever I am writing tests I can simply type "assert", hit ctrl+space for auto completion, get a list of possible methods from the org.junit.Assert class that start with "assert", choose the one that I want, and Eclipse automatically static import it.

If I am working on a project, however, I tend to follow whatever exists - even reverting my IDE changes.

Just my 0.02 cents.

Cheers
Bruno

[1] https://stackoverflow.com/questions/288861/eclipse-optimize-imports-to-include-static-imports


________________________________
From: Gilles <[hidden email]>
To: [hidden email]
Sent: Monday, 16 October 2017 10:08 PM
Subject: Re: [text] always use static imports for assertion methods



On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:

>> Am 16.10.2017 um 00:34 schrieb Gilles
>> <[hidden email]>:
>>
>> 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...]


Gilles

> Cheers,
> Benedikt
>
>>
>> YMMV,
>> Gilles
>>
>>
>>> On 15 October 2017 at 13:44, Gilles <[hidden email]>
>>> wrote:
>>>
>>>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>>>
>>>>> Just for consistency.
>>>>>
>>>>
>>>> Consistency is fine. ;-)
>>>>
>>>> All almost all tests already used static
>>>>> imports, so I adjusted the few that did not.
>>>>>
>>>>
>>>> It's the use of "import static" which I was questioning.
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>>> -Pascal
>>>>>
>>>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>>>
>>>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC),
>>>>>> [hidden email]
>>>>>> wrote:
>>>>>>
>>>>>>> Repository: commons-text
>>>>>>> Updated Branches:
>>>>>>>  refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>>>
>>>>>>>
>>>>>>> always use static imports for assertion methods
>>>>>>>
>>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Gilles Sadowski
On Mon, 16 Oct 2017 09:22:51 +0000 (UTC), Bruno P. Kinoshita wrote:
>>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.
>
> But the internal class could be named Assert.

And that would be bad choice, knowing full well that a de-facto
standard library uses that name.

> In that case you still
> wouldn't know if it was imported from JUnit until you looked at the
> import statements.

The more you import, the more you risk having to look,
indeed. Hence...

> Said that, I don't use that argument to decide on static imports or
> not. I do use static imports most of the times. And my main reason is
> Eclipse import favourites. I have a few favourites [1] configured,
> including JUnit Assert class.

We should not assume any particular environment for
development. Especially if one developer's facilities
create a burden for others.

> That way, whenever I am writing tests I can simply type "assert", hit
> ctrl+space for auto completion, get a list of possible methods from
> the org.junit.Assert class that start with "assert", choose the one
> that I want, and Eclipse automatically static import it.

I guess that Eclipse could just as easily write the the class
name for you, at the point when you typed "assert".

> If I am working on a project, however, I tend to follow whatever
> exists - even reverting my IDE changes.

Unless I'm mistaken, static import were always discouraged
(here and elsewhere).  There isn't a single advantage for a
reader of the source.
Through tools like CheckStyle, we enforce rules that are much
more innocuous if not followed...

Soon, the same arguments will be applied to tabs vs spaces.
[Since a GUI IDE "smart" editor is able to display the code
right, whatever.]


Best,
Gilles

>
> Just my 0.02 cents.
>
> Cheers
> Bruno
>
> [1]
>
> https://stackoverflow.com/questions/288861/eclipse-optimize-imports-to-include-static-imports
>
>
> ________________________________
> From: Gilles <[hidden email]>
> To: [hidden email]
> Sent: Monday, 16 October 2017 10:08 PM
> Subject: Re: [text] always use static imports for assertion methods
>
>
>
> On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:
>>> Am 16.10.2017 um 00:34 schrieb Gilles
>>> <[hidden email]>:
>>>
>>> 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...]
>
>
> Gilles
>
>> Cheers,
>> Benedikt
>>
>>>
>>> YMMV,
>>> Gilles
>>>
>>>
>>>> On 15 October 2017 at 13:44, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>>>>
>>>>>> Just for consistency.
>>>>>>
>>>>>
>>>>> Consistency is fine. ;-)
>>>>>
>>>>> All almost all tests already used static
>>>>>> imports, so I adjusted the few that did not.
>>>>>>
>>>>>
>>>>> It's the use of "import static" which I was questioning.
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>> -Pascal
>>>>>>
>>>>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>>>>
>>>>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC),
>>>>>>> [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Repository: commons-text
>>>>>>>> Updated Branches:
>>>>>>>>  refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>>>>
>>>>>>>>
>>>>>>>> always use static imports for assertion methods
>>>>>>>>
>>>>>>>>
>>>>>>> Why?
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>
>>>
>>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Benedikt Ritter-4
In reply to this post by Gilles Sadowski
Hello Gilles,

> Am 16.10.2017 um 11:07 schrieb Gilles <[hidden email]>:
>
> On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:
>>> Am 16.10.2017 um 00:34 schrieb Gilles <[hidden email]>:
>>>
>>> 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. So I don’t see a reason to start yet another endless discussion.

Benedikt

>
> Gilles
>
>> Cheers,
>> Benedikt
>>
>>>
>>> YMMV,
>>> Gilles
>>>
>>>
>>>> On 15 October 2017 at 13:44, Gilles <[hidden email]> wrote:
>>>>
>>>>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>>>>
>>>>>> Just for consistency.
>>>>>>
>>>>>
>>>>> Consistency is fine. ;-)
>>>>>
>>>>> All almost all tests already used static
>>>>>> imports, so I adjusted the few that did not.
>>>>>>
>>>>>
>>>>> It's the use of "import static" which I was questioning.
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>> -Pascal
>>>>>>
>>>>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>>>>
>>>>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Repository: commons-text
>>>>>>>> Updated Branches:
>>>>>>>> refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>>>>
>>>>>>>>
>>>>>>>> always use static imports for assertion methods
>>>>>>>>
>>>>>>>>
>>>>>>> Why?
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

Gilles Sadowski
On Mon, 16 Oct 2017 12:09:27 +0200, Benedikt Ritter wrote:

> Hello Gilles,
>
>> Am 16.10.2017 um 11:07 schrieb Gilles
>> <[hidden email]>:
>>
>> On Mon, 16 Oct 2017 09:30:01 +0200, Benedikt Ritter wrote:
>>>> Am 16.10.2017 um 00:34 schrieb Gilles
>>>> <[hidden email]>:
>>>>
>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

garydgregory
In reply to this post by Gilles Sadowski
On Oct 15, 2017 16:34, "Gilles" <[hidden email]> wrote:

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 do as well.

Gary


YMMV,
Gilles



On 15 October 2017 at 13:44, Gilles <[hidden email]> wrote:

>
> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
>>
>> Just for consistency.
>>>
>>>
>> Consistency is fine. ;-)
>>
>> All almost all tests already used static
>>
>>> imports, so I adjusted the few that did not.
>>>
>>>
>> It's the use of "import static" which I was questioning.
>>
>> Gilles
>>
>>
>>
>> -Pascal
>>>
>>> Am 15.10.2017 um 11:44 schrieb Gilles:
>>>
>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
>>>> wrote:
>>>>
>>>> Repository: commons-text
>>>>> Updated Branches:
>>>>>   refs/heads/master 51645b4f0 -> 8f7d0494d
>>>>>
>>>>>
>>>>> always use static imports for assertion methods
>>>>>
>>>>>
>>>>> Why?
>>>>
>>>> Gilles
>>>>
>>>>
>>>> [...]
>>>>>
>>>>>
>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [text] always use static imports for assertion methods

kenneth mcfarland
The inclusion of static imports is fairly common in the context Matt
provided.  One could easily argue that polluting names with another
assertEquals method was a bad design decision. Especially when you have
made a concisious design decision to use JUnit.
Is it likely to cause confusion in real practice?

In math, if the the context is not clear you let the reader know. For
instance:

What is the solution to y = x/2 . Not so fast. What if x is in Z or N,
where fractions are forbidden? So rephrase the question: what is the
solution to x/2 where x in R, now its clear. It's a good idea to let people
know where things live if you can reasonable expect ambiguity.

I would assume to take the same approach here for clarity.


On Mon, Oct 16, 2017 at 6:14 AM, Gary Gregory <[hidden email]>
wrote:

> On Oct 15, 2017 16:34, "Gilles" <[hidden email]> wrote:
>
> 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 do as well.
>
> Gary
>
>
> YMMV,
> Gilles
>
>
>
> On 15 October 2017 at 13:44, Gilles <[hidden email]> wrote:
> >
> > On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote:
> >>
> >> Just for consistency.
> >>>
> >>>
> >> Consistency is fine. ;-)
> >>
> >> All almost all tests already used static
> >>
> >>> imports, so I adjusted the few that did not.
> >>>
> >>>
> >> It's the use of "import static" which I was questioning.
> >>
> >> Gilles
> >>
> >>
> >>
> >> -Pascal
> >>>
> >>> Am 15.10.2017 um 11:44 schrieb Gilles:
> >>>
> >>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), [hidden email]
> >>>> wrote:
> >>>>
> >>>> Repository: commons-text
> >>>>> Updated Branches:
> >>>>>   refs/heads/master 51645b4f0 -> 8f7d0494d
> >>>>>
> >>>>>
> >>>>> always use static imports for assertion methods
> >>>>>
> >>>>>
> >>>>> Why?
> >>>>
> >>>> Gilles
> >>>>
> >>>>
> >>>> [...]
> >>>>>
> >>>>>
> >>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>