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

"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

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