Re[2]: [equinox-dev] Coding standards: using import abc.* - or not?

[Oleg Besedin <obesedin@xxxxxxxxxx>]

Hi Peter,
Sorry, I should have explained better
the scenario I run into.

Let's say we have a plugin ABC that:
        a)
has an Assert class in the package ABC, and
        b)
uses runtime. 

In this case a typical import code in
the plugin ABC would be:

        import
org.eclipse.core.runtime.*;
        import
ABC.*;
        ...
        Assert.isTrue(isMoonFull);
        ...

Which works fine - until somebody notices
that "Assert" class is duplicated 8 times in different plugins.
With that in mind somebody adds "Assert" as a public API to the
package org.eclipse.core.runtime. Now developers won't have to duplicate
"Assert" class anymore and the world is a better place.

You probably guessed what happens next:
plugin ABC doesn't compile anymore as "import .* " statements
become ambiguous. (By the way, no changes were made to the plugin ABC in
the process - yet it doesn't compile anymore.)


Sincerely,
Oleg Besedin



Peter Kriens <Peter.Kriens@xxxxxxxx>:

> -1
> 
> I like the import abc.* very much because it is easier to see what
> packages are used, less redundant information is easier to grasp.
> Coupling takes place on package level, not class level. The root of
> most software evil is redundancy.
> 
> I do not understand the problems:
> 
> - Identical names are rare and confusing anyway.
> - F3 brings you to the definition regardless of the import