www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - BUG - Interface implementation on derived class

reply Antonio Monteiro <duitoolkit yahoo.ca> writes:
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;
}
Apr 05 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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 ...



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



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
Apr 05 2005
parent reply Ant <Ant_member pathlink.com> writes:
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



 Apr 05 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


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



 Apr 05 2005



  parent reply Ant <Ant_member pathlink.com>  writes:


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



 Apr 05 2005



  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


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 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



 Apr 05 2005



  parent reply Ant <Ant_member pathlink.com>  writes:


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 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



 Apr 05 2005



  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Wed, 6 Apr 2005 01:42:39 +0000 (UTC), Ant <Ant_member pathlink.com>  
wrote:

 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 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!


Yes.. that's what I meant. :) There are no other solutions AKA  
"workarounds"


 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.


Hmm.. not sure I like the "look" of that.


 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?)


I think it works. I imagine you can test it by doing a private import and  
trying to access a member of that module by importing the module with the  
private import. (what is 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...


Actually my impression is that Walter doesn't agree there is a problem  
with import.

My only problem with import is that I believe import should default to  
'private'. I have to type "private" in front of just about all my imports,  
on the rare occasion where I am importing module specific (i.e. not  
std.string) public data (i.e. not just used internally to this module) do  
I leave the "private" off.

The argument that "everything else" is public so "import" should also be  
public is <impolite>*bollocks*</impolite>. "everything else" isn't the  
same as "import". apples and oranges. etc.

Regan



 Apr 05 2005



 next sibling parent  Antonio Monteiro <duitoolkit yahoo.ca>  writes:


 with the  private import. (what is TK?)


Mr. Thomas Kuehne! the http://dstress.kuehne.cn/ guy.

Ant



 Apr 05 2005



prev sibling  parent  Derek Parnell <derek psych.ward>  writes:


On Wed, 06 Apr 2005 16:30:24 +1200, Regan Heath wrote:


 On Wed, 6 Apr 2005 01:42:39 +0000 (UTC), Ant <Ant_member pathlink.com>  
 wrote:

 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 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!


 
 Yes.. that's what I meant. :) There are no other solutions AKA  
 "workarounds"
 

 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.


 
 Hmm.. not sure I like the "look" of that.
 

 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?)


 
 I think it works. I imagine you can test it by doing a private import and  
 trying to access a member of that module by importing the module with the  
 private import. (what is 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...


 
 Actually my impression is that Walter doesn't agree there is a problem  
 with import.
 
 My only problem with import is that I believe import should default to  
 'private'. I have to type "private" in front of just about all my imports,  
 on the rare occasion where I am importing module specific (i.e. not  
 std.string) public data (i.e. not just used internally to this module) do  
 I leave the "private" off.
 
 The argument that "everything else" is public so "import" should also be  
 public is <impolite>*bollocks*</impolite>. "everything else" isn't the  
 same as "import". apples and oranges. etc.
 


Yes. I'm always using "private import" too. I can't see a good (useful) use
for public imports yet. A public import is a bit impertinent by my
thinking. It says "Oh by the way, when you use my module 'x', you must also
be wanting to directly use the modules that 'x' uses too, so I'm doing you
a favor by making them available for you.". Ahhhh...but what if I wasn't
intending to use that stuff - now I've got namespace clashes that I'm
forced to resolve. Thank you, but if I need any of that stuff I'll import
it myself, okay?


It does get a bit tedious, but I'm sort of used to typing ...

private {
   import ... ;
   import ... ;
 }

at the top of all my modules.

-- 
Derek
Melbourne, Australia
6/04/2005 2:47:00 PM



 Apr 05 2005



prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz>  writes:


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



 Apr 05 2005



  parent reply Ant <Ant_member pathlink.com>  writes:


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



 Apr 05 2005



  parent  "Regan Heath" <regan netwin.co.nz>  writes:


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



 Apr 05 2005



prev sibling  parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Antonio Monteiro schrieb am Tue, 05 Apr 2005 03:24:23 -0400:

 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)
          {
          }
 }


<snip>

The only place wher ImportDeclarations are legal is the module scope.
(http://digitalmars.com/d/module.html)

Added to DStress as
http://dstress.kuehne.cn/nocompile/import_01.d
http://dstress.kuehne.cn/nocompile/import_02.d
http://dstress.kuehne.cn/nocompile/import_03.d
http://dstress.kuehne.cn/nocompile/import_04.d
http://dstress.kuehne.cn/nocompile/import_05.d

Thomas



-----BEGIN PGP SIGNATURE-----

iD8DBQFCU5pu3w+/yD4P9tIRAhVMAKCGEXKMNO55pZm8qP1kHBALU/jitgCfciZc
m6btEEkJhsEjXidQaSmUSc4=
=/PHZ
-----END PGP SIGNATURE-----



 Apr 06 2005



  parent  Ant <Ant_member pathlink.com>  writes:


In article <ecici2-tg5.ln1 lnews.kuehne.cn>, Thomas Kuehne says...



The only place wher ImportDeclarations are legal is the module scope.


Thank you, this is good to know.
I tried to confirm that 1.5 years ago but couldn't.
Now I can do things how D is suppose to support them...

Ant



 Apr 06 2005