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!
If you give your classes stupid names,
expect them to clash.
Solution, name them something sensible.
--
Andrew Thompson
* http://www.PhySci.org/ Open-source software suite
* http://www.PhySci.org/codes/ Web & IT Help
* http://www.1point1C.org/ Science & Technology
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
*********************************************************
>
>
> Thanks!
>
Andrew Thompson wrote:
> Jacob wrote:
>
>>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.
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.
> Andrew,
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.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'I' is the most beautiful word in the world."
- John Nordberg
> 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?
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...
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
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 ma...@ivizNOSPAM.com http://www.iviz.com/
"Matt Humphrey" <ma...@ivizNOSPAM.com> wrote in message
news:4uidnRU5GeE...@adelphia.com...
In Java 1.6 we definitely need an "unimport" statement,
and to allow imports and unimports in any block scope ;-)
-Larry Barowski
> 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;
"Jacob" <ja...@yahoo.com> wrote in message
news:QdHUb.1998$_c4....@news4.e.nsc.no...
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)
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;
--
Dale King
That was meant to be language design humor.
-Larry Barowski