• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (21/21) Sep 06 2005 A few weeks ago I had some problems with class hierarchies and imports.
• Ben Hinkle (14/35) Sep 06 2005 If there's a chain of public imports leading to a module then you'll get...
• Carlos Santander (21/48) Sep 06 2005 Well, in Java, given this pair of files:

=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:

A few weeks ago I had some problems with class hierarchies and imports. 
Ben suggested that I should use private imports. Ok, the thing is I 
_did_ use both of them but didn't see much difference between the two.

I made some more tests and found out that on some occasions it's 
possible to instantiate classes that are on the other end of the private 
import chain. I did use several cross-references between the files 
(modules). Still I think there's something fishy here.

This behaviour really started to annoy me when the compiler didn't want 
to compile stuff and told me I had some conflicting class names like 
BaseClassModule.BaseClass and DerivedClassModule.BaseClass.

There seems to be only four (IMHO bad) solutions to this:
- I can move some of the "global" import lines inside the classes that 
need them. (I still don't understand why this fixes this)
- I can tune the imports so that "high level" classes don't directly 
import "lower level" things like interfaces or base classes.
- I can explicitely define, which classes I wish to use, eg. a.foo f = 
new a.foo();
- I can write everything in the same file :(

I have never encountered these problems with C++/Java. I'll try to post 
some practical test cases when I have more time.


Jari-Matti

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message 
news:dfksjh$1ke1$1 digitaldaemon.com...
A few weeks ago I had some problems with class hierarchies and imports. Ben 
suggested that I should use private imports. Ok, the thing is I _did_ use 
both of them but didn't see much difference between the two.

 I made some more tests and found out that on some occasions it's possible 
 to instantiate classes that are on the other end of the private import 
 chain. I did use several cross-references between the files (modules). 
 Still I think there's something fishy here.

If there's a chain of public imports leading to a module then you'll get the 
public behavior. For example if you have something like

 module bar;
 import foo;

 module baz;
 import bar;
 private import foo;

then even though baz says it private imports foo it already publically 
imported foo via bar. Without more information about your particular case 
it's hard to give any concrete advice.

 This behaviour really started to annoy me when the compiler didn't want to 
 compile stuff and told me I had some conflicting class names like 
 BaseClassModule.BaseClass and DerivedClassModule.BaseClass.

 There seems to be only four (IMHO bad) solutions to this:
 - I can move some of the "global" import lines inside the classes that 
 need them. (I still don't understand why this fixes this)
 - I can tune the imports so that "high level" classes don't directly 
 import "lower level" things like interfaces or base classes.
 - I can explicitely define, which classes I wish to use, eg. a.foo f = new 
 a.foo();
 - I can write everything in the same file :(

 I have never encountered these problems with C++/Java. I'll try to post 
 some practical test cases when I have more time.

Posting code would help. I can't figure out what your code looks like from 
the above information.

 Jari-Matti 

Carlos Santander <csantander619 gmail.com> writes:

Jari-Matti Mäkelä escribió:
 A few weeks ago I had some problems with class hierarchies and imports. 
 Ben suggested that I should use private imports. Ok, the thing is I 
 _did_ use both of them but didn't see much difference between the two.
 
 I made some more tests and found out that on some occasions it's 
 possible to instantiate classes that are on the other end of the private 
 import chain. I did use several cross-references between the files 
 (modules). Still I think there's something fishy here.
 
 This behaviour really started to annoy me when the compiler didn't want 
 to compile stuff and told me I had some conflicting class names like 
 BaseClassModule.BaseClass and DerivedClassModule.BaseClass.
 
 There seems to be only four (IMHO bad) solutions to this:
 - I can move some of the "global" import lines inside the classes that 
 need them. (I still don't understand why this fixes this)
 - I can tune the imports so that "high level" classes don't directly 
 import "lower level" things like interfaces or base classes.
 - I can explicitely define, which classes I wish to use, eg. a.foo f = 
 new a.foo();
 - I can write everything in the same file :(
 
 I have never encountered these problems with C++/Java. I'll try to post 
 some practical test cases when I have more time.
 
 
 Jari-Matti

Well, in Java, given this pair of files:

package p1;
public class Class1 {}

package p2;
public class Class1 {}

You can't do either of these:

package p3;
import p1.Class1;
import p2.Class1;
public class Class2 {}

package p4;
import p1.*;
import p2.*;
public class Class3 { Class1 c; }

In p3.Class2 you can only make one of those imports and fully qualify the
other. 
In p4.Class3 you have to fully qualify Class1 everytime. So I don't know see
how 
it's any different. Even more, I think it might actually be better in D (but I 
can't think of any examples right now).

-- 
Carlos Santander Bernal