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

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

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

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

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

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

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!

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

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!

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.

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

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