class name clash

[Jacob]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

Obviously I can't do:

import my.company.some.package.a.*;
import my.company.some.package.b.*;

as there whould be a name clash.

Rather I have to do this (for instance):

import.my.company.some.package.a.*;

MyClass myClass1;
import.my.company.some.package.b.MyClass myClass2;


Why am I not allowed to do this:

import my.company.some.package.*;

a.MyClass myClass1;
b.MyClass myClass2;


Thanks!

 

[Andrew Thompson]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

If you give your classes stupid names,
expect them to clash.

Solution, name them something sensible.

 

[Andrew Hobbs]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

Obviously I can't do:

import my.company.some.package.a.*;
import my.company.some.package.b.*;

as there whould be a name clash.

Rather I have to do this (for instance):

import.my.company.some.package.a.*;

MyClass myClass1;
import.my.company.some.package.b.MyClass myClass2;


Why am I not allowed to do this:

import my.company.some.package.*;

a.MyClass myClass1;
b.MyClass myClass2;

Because in the Java scheme of things, there is no heirarchy of packages.
Each package is completely independent of others. The tree structure is
just a convenient way of organizing the folders/packages for the
programmer/user. ie.

import my.company.some.package.*

imports only those classes within that particular folder. It has no
reference or knowledge of other packages even though the classes may be in a
sub folder.

Cheers

Andrew


--
********************************************************
Andrew Hobbs PhD

MetaSense Pty Ltd - www.metasense.com.au
12 Ashover Grove
Carine W.A.
Australia 6020

61 8 9246 2026
metasens AntiSpam @iinet dot net dot au


*********************************************************

 

[Jacob]

If you give your classes stupid names,
expect them to clash.

Andrew,

Names doesn't clash because they are stupid, but
because they are equal. This may happen often in
large systems, and are also the case in the JDK.

And: If you have nothing to contribute with,
then don't. There are to much spam already.

 

[Joona I Palaste]

Names doesn't clash because they are stupid, but
because they are equal. This may happen often in
large systems, and are also the case in the JDK.

And: If you have nothing to contribute with,
then don't. There are to much spam already.

Seems to me like Andrew had a quite sensible thing to contribute: don't
give your classes stupid names. The two names you've provided above are
quite stupid. If you're now going to tell us "they're not the _real_
names", then please also tell us how you expect us to know what the
real names are, then.

 

[Jacob]

Seems to me like Andrew had a quite sensible thing to contribute: don't
give your classes stupid names. The two names you've provided above are
quite stupid. If you're now going to tell us "they're not the _real_
names", then please also tell us how you expect us to know what the
real names are, then.

Andrews contribution is quite valid: Nobody should
ever give their classes stupid names!

But his remark doesn't belong in this thread.

I was asking a general question and included an
example to make my point clear. In my specific case
there are, as you correctly imply, some *other*
names involved, but if I gave you those, whould
your answer be any different?

 

[Andrew Thompson]

....
I was asking a general question and included an
example to make my point clear. In my specific case
there are, as you correctly imply, some *other*
names involved,

What are they, secret?

..but if I gave you those, whould
your answer be any different?

That depends, you still have not given
these hypothetical names. So...

 

[Peter Kirk]

If you give your classes stupid names,
expect them to clash.

Solution, name them something sensible.

What an interesting thread developing here! I would say that if you name
your classes something stupid they are *less* likely to clash.

The class "jhgz.kuf.sdflij.Ldlkjhvui" is highly unlikely to clash with other
random and stupid names. So to avoid clashes, I recommend stupid names.

On the other hand if I named my class something sensible like
"dk.kommune.graph.Node" then it just might clash with any of several
sensibly named Node classes. And there are a lot of Node classes out there.

Peter

 

[Matt Humphrey]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

Obviously I can't do:

import my.company.some.package.a.*;
import my.company.some.package.b.*;

as there whould be a name clash.

You can do this, but you still have to use the full name to disambiguate the
classes. This is just like
import java.awt.*
import java.util.*

While having to say
java.util.List list = new ArrayList ();

Rather I have to do this (for instance):

import.my.company.some.package.a.*;

MyClass myClass1;
import.my.company.some.package.b.MyClass myClass2;

From the JLS 7.5, "An import declaration allows a named type to be referred
to by a simple name that consists of a single identifier." In 7.5.1 we get
exactly the case you're describing: "Note that an import statement cannot
import a subpackage, only a type." Import doesn't really import anything
(does not make the types accessible.) It's a means for referring to types
by their simple names.

Why am I not allowed to do this:

import my.company.some.package.*;

a.MyClass myClass1;
b.MyClass myClass2;

It would be nice if this were possible, particular in the instance that you
describe where you need to disambiguate only part of the class name. I
havn't found in the JLS why it's done this way, but I would think, though,
that the ambiguity of not knowing whether a name is a fully-qualified or
partial is not worth the benefit for the rare cases where there are
duplicate class names in different packages.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[nos]

"Date" exists in SQL and also UTIL in the SDK

You can do this, but you still have to use the full name to disambiguate the
classes. This is just like
import java.awt.*
import java.util.*

While having to say
java.util.List list = new ArrayList ();


From the JLS 7.5, "An import declaration allows a named type to be referred
to by a simple name that consists of a single identifier." In 7.5.1 we get
exactly the case you're describing: "Note that an import statement cannot
import a subpackage, only a type." Import doesn't really import anything
(does not make the types accessible.) It's a means for referring to types
by their simple names.


It would be nice if this were possible, particular in the instance that you
describe where you need to disambiguate only part of the class name. I
havn't found in the JLS why it's done this way, but I would think, though,
that the ambiguity of not knowing whether a name is a fully-qualified or
partial is not worth the benefit for the rare cases where there are
duplicate class names in different packages.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Larry Barowski]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

Obviously I can't do:

import my.company.some.package.a.*;
import my.company.some.package.b.*;

as there whould be a name clash.

...

In Java 1.6 we definitely need an "unimport" statement,
and to allow imports and unimports in any block scope ;-)

-Larry Barowski

 

[Tor Iver Wilhelmsen]

In Java 1.6 we definitely need an "unimport" statement,
and to allow imports and unimports in any block scope ;-)

Or we could add aliasing like, say, C# and Python has.

C#:
using Cons = System.Console;

Python (Jython in this case):

from java.awt import List
AWTList = List # Create alias
from java.util import List

Possibly in some later Java version:

import AWTList = java.awt.List;

 

[Tony Morris]

I have two classes like this:

my.company.some.package.a.MyClass
my.company.some.package.b.MyClass

Obviously I can't do:

import my.company.some.package.a.*;
import my.company.some.package.b.*;

as there whould be a name clash.

Rather I have to do this (for instance):

import.my.company.some.package.a.*;

MyClass myClass1;
import.my.company.some.package.b.MyClass myClass2;


Why am I not allowed to do this:

import my.company.some.package.*;

a.MyClass myClass1;
b.MyClass myClass2;


Thanks!

Fully qualify your imports, and/or fully qualify the use of the class name.
e.g.

import java.awt.*;
import java.util.List;
// a List reference is a java.util.List
// a java.awt.List reference is a java.awt.List

import java.awt.List;
import java.util.List;
// compile-time error (according to JLS), but I have found anomolies on
various compilers.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Dale King]

In Java 1.6 we definitely need an "unimport" statement,
and to allow imports and unimports in any block scope ;-)

No we don't. Only one of them can be the one that is referenced without
qualification, all others must be qualified. As you show it both the a and b
versions must be qualified. To use one of them unqualified you just have to
tell the compiler which one:

import my.company.some.package.a.*;
import my.company.some.package.b.*;
import my.company.some.package.a.MyClass;

 

[Larry Barowski]

No we don't. ...

That was meant to be language design humor.

-Larry Barowski