Here is a problem I got using interfaces and classes
(lets keep it simple)

I reduced it to 6 modules and no external dependencies

Walter, let me know if I can do something else.

################################
here is the compiler command:
dmd a.d b.d c.d dummy.d i.d util.d -I~/dmd/src/phobos
################################
and the 6 source files:
################################
module a;
class A
{
}
################################
module b;
private import a;
private import i;

class B : A , I
{
        private import util;
        private import dummy;

        public A foo(Util util)
        {
        }
}
################################
module c;

private import b;
public class C : B
{
}
################################
module dummy;
public:
class Dummy
{
}
################################
module i;

public:
interface I
{
        private import a;
        private import util;

        public A foo(Util util);
}
##############################
module util;
class Util
{
        private import c;
}

On Tue, 05 Apr 2005 03:24:23 -0400, Antonio Monteiro wrote:

> Here is a problem I got using interfaces and classes
> (lets keep it simple)
> 
> I reduced it to 6 modules and no external dependencies
> 
> Walter, let me know if I can do something else.
> 
> ################################
> here is the compiler command:
> dmd a.d b.d c.d dummy.d i.d util.d -I~/dmd/src/phobos

It has to do with the sequence that these modules are compiled in. Try this sequence instead ...

# dmd i.d c.d dummy.d b.d util.d a.d -I~/dmd/src/phobos -c

I got this sequence because I used my Build utility thus ...

# build util

and it worked out the sequence.

Hope this helps.
-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v1.19 released 04/Apr/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
5/04/2005 5:41:20 PM

Changes below...

On Tue, 05 Apr 2005 03:24:23 -0400, Antonio Monteiro <duitoolkit@yahoo.ca> wrote:
> dmd a.d b.d c.d dummy.d i.d util.d -I~/dmd/src/phobos
> ################################
> and the 6 source files:
> ################################
> module a;
> class A
> {
> }
> ################################
> module b;
> private import a;
> private import i;
>  class B : A , I
> {

move these imports outside the class definition.
>         private import util;
>         private import dummy;

>          public A foo(Util util)
>         {
>         }
> }
> ################################
> module c;
>  private import b;
> public class C : B
> {
> }
> ################################
> module dummy;
> public:
> class Dummy
> {
> }
> ################################
> module i;
>  public:
> interface I
> {

move these imports outside the class definition.
>         private import a;
>         private import util;

>          public A foo(Util util);
> }
> ##############################
> module util;
> class Util
> {

move these imports outside the class definition.
>         private import c;

> }

I did the above, and created a main.d containing "void main() {}" and it compiles A-ok.

What is the purpose of placing the imports within the class?

Regan

In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>

>It has to do with the sequence that these modules are compiled in. Try this sequence instead ...
>
But we are not trying to find a workaround, we are halping Walter to correct what seems to be a bug on the compiler.

Ant

In article <opsoq2dtna23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>
>move these imports outside the class definition.
[...]
>move these imports outside the class definition.
[...]
>move these imports outside the class definition.
[...]

>I did the above, and created a main.d containing "void main() {}" and it compiles A-ok.
>
>What is the purpose of placing the imports within the class?

The imports are not going to be used outside of the class body.
Why sould they be declared outside of the class body? makes no sence.
I moved the import to the class body as a workaround for the
"forward reference" nightmare, but it's clearly where they belong.

Thank you for the workaround but the porpuse is to fix a compiler bug.

Ant

On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:

> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>>
> 
>>It has to do with the sequence that these modules are compiled in. Try this sequence instead ...
>>
> But we are not trying to find a workaround, we are halping Walter to correct what seems to be a bug on the compiler.

(1) I wasn't suggesting a workaround, that was incidental.
(2) You might not be after a workaround, but somebody else might be.
(3) I was demonstrating that under different conditions, the issue has
different manifestations, and thus that fact might be useful in the problem
determination.

Sorry I made myself so obscure.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
6/04/2005 7:16:38 AM

On Tue, 5 Apr 2005 13:57:26 +0000 (UTC), Ant <Ant_member@pathlink.com> wrote:
> In article <opsoq2dtna23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>>
>> move these imports outside the class definition.
> [...]
>> move these imports outside the class definition.
> [...]
>> move these imports outside the class definition.
> [...]
>
>> I did the above, and created a main.d containing "void main() {}" and it
>> compiles A-ok.
>>
>> What is the purpose of placing the imports within the class?
>
> The imports are not going to be used outside of the class body.
> Why sould they be declared outside of the class body? makes no sence.
> I moved the import to the class body as a workaround for the
> "forward reference" nightmare, but it's clearly where they belong.
>
> Thank you for the workaround but the porpuse is to fix a compiler bug.

What Derek said :)

Regan

In article <13jkf6n6kcyyc$.178nuu0td92rz.dlg@40tude.net>, Derek Parnell says...
>
>On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:
>
>> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>>>
>> 
>>>It has to do with the sequence that these modules are compiled in. Try this sequence instead ...
>>>
>> But we are not trying to find a workaround, we are halping Walter to correct what seems to be a bug on the compiler.
>
>(1) I wasn't suggesting a workaround, that was incidental.
>(2) You might not be after a workaround, but somebody else might be.
>(3) I was demonstrating that under different conditions, the issue has
>different manifestations, and thus that fact might be useful in the problem
>determination.
>
>Sorry I made myself so obscure.

It's probably my fault guys, I should have than you for the workaround.

Ant

On Tue, 5 Apr 2005 22:02:54 +0000 (UTC), Ant <Ant_member@pathlink.com> wrote:
> In article <13jkf6n6kcyyc$.178nuu0td92rz.dlg@40tude.net>, Derek Parnell says...
>>
>> On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:
>>
>>> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>>>>
>>>
>>>> It has to do with the sequence that these modules are compiled in. Try this
>>>> sequence instead ...
>>>>
>>> But we are not trying to find a workaround, we are halping Walter to
>>> correct what seems to be a bug on the compiler.
>>
>> (1) I wasn't suggesting a workaround, that was incidental.
>> (2) You might not be after a workaround, but somebody else might be.
>> (3) I was demonstrating that under different conditions, the issue has
>> different manifestations, and thus that fact might be useful in the problem
>> determination.
>>
>> Sorry I made myself so obscure.
>
> It's probably my fault guys, I should have than you for the workaround.

No worries Ant, I can understand your position, you don't want a workaround you want the bug fixed. I would be the same.

I suspect that finding a workaround can help Walter find the bug and if the workaround is yucky enough convince him it is a bug that needs to be fixed ASAP.

Where you said:
> The imports are not going to be used outside of the class body.
> Why sould they be declared outside of the class body? makes no sence.
> I moved the import to the class body as a workaround for the
> "forward reference" nightmare, but it's clearly where they belong.

I understand, but lets explore this a bit as in certain situations it appears to make no difference to the outcome (except to highlight bugs as it has done in this case)...

--[main.d]--
import inside;
import outside;
void main() {}

--[outside.d]--
private import other;
class A { ..use other.. }

--[inside.d]--
class A {
  private import other;
}

whether the import is inside or outside the class, makes no difference to main.d (as it's a private import). As there is only 1 class "A" it makes no difference in the modules either.

Now, if the import was public, or there were 2 classes eg.

--[now.d]--
import other;
class A {
  ..use other..
}
class B {
  ..dont use other..
}

1- main would be polluted with symbols from other.
2- class B would be polluted with symbols from other.

To solve #1 you place 'private' on the import.

#2 has no solution, except to place the import in the class A.

To me this pollution is acceptable as the pollution itself causes very little adverse effect, it is possible to get collisions, if so, use alias. The trade off I get is that later, if I add another class, or start to use 'other' in B I don't have to move/copy my imports around the place.

So there you have my 2c on imports within classes. I don't use them.

Regan

In article <opsor5vxo123k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Tue, 5 Apr 2005 22:02:54 +0000 (UTC), Ant <Ant_member@pathlink.com> wrote:
>> In article <13jkf6n6kcyyc$.178nuu0td92rz.dlg@40tude.net>, Derek Parnell says...
>>>
>>> On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:
>>>
>>>> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>>>>>
>>>>
>>>>> It has to do with the sequence that these modules are compiled in.
>>>>> Try this
>>>>> sequence instead ...
>>>>>
>>>> But we are not trying to find a workaround, we are halping Walter to correct what seems to be a bug on the compiler.
>>>
>>> (1) I wasn't suggesting a workaround, that was incidental.
>>> (2) You might not be after a workaround, but somebody else might be.
>>> (3) I was demonstrating that under different conditions, the issue has
>>> different manifestations, and thus that fact might be useful in the
>>> problem
>>> determination.
>>>
>>> Sorry I made myself so obscure.
>>
>> It's probably my fault guys, I should have than you for the workaround.
>
>No worries Ant, I can understand your position, you don't want a workaround you want the bug fixed. I would be the same.
>
>I suspect that finding a workaround can help Walter find the bug and if the workaround is yucky enough convince him it is a bug that needs to be fixed ASAP.
>
>Where you said:
>> The imports are not going to be used outside of the class body.
>> Why sould they be declared outside of the class body? makes no sence.
>> I moved the import to the class body as a workaround for the
>> "forward reference" nightmare, but it's clearly where they belong.
>
>I understand, but lets explore this a bit as in certain situations it appears to make no difference to the outcome (except to highlight bugs as it has done in this case)...
>
>--[main.d]--
>import inside;
>import outside;
>void main() {}
>
>--[outside.d]--
>private import other;
>class A { ..use other.. }
>
>--[inside.d]--
>class A {
>   private import other;
>}
>
>whether the import is inside or outside the class, makes no difference to main.d (as it's a private import). As there is only 1 class "A" it makes no difference in the modules either.
>
>Now, if the import was public, or there were 2 classes eg.
>
>--[now.d]--
>import other;
>class A {
>   ..use other..
>}
>class B {
>   ..dont use other..
>}
>
>1- main would be polluted with symbols from other.
>2- class B would be polluted with symbols from other.
>
>To solve #1 you place 'private' on the import.
>
>#2 has no solution, except to place the import in the class A.
>
>To me this pollution is acceptable as the pollution itself causes very little adverse effect, it is possible to get collisions, if so, use alias. The trade off I get is that later, if I add another class, or start to use 'other' in B I don't have to move/copy my imports around the place.
>
>So there you have my 2c on imports within classes. I don't use them.
>
>Regan

So you say "has no solution, expect...". That's no exception! that's the solution!

I would take my view a bit further and allow the full qualified
import to be declared on the class header:
class B : mylib.utils.A , mylib.utils.I {...}
and so avoid any polution form any import.
This would be irrelevant to me if I could place one class per module
and 'private' really worked on the import
(does it work now? how is it tested? TK?)
The real problem is that Walter has the import thing very low on his
priority list. That makes it very brittle and me very afraid...

Ant