digitalmars.D.bugs - Interface implementation on derived class
- Ant (15/15) Apr 03 2005 (of course an actual code example is right way to do this. I'm first
- Derek Parnell (15/30) Apr 03 2005 I assume you have CodeBlock defined along the lines of ...
- Ant (6/32) Apr 03 2005 I know that what I have is
- Ben Hinkle (1/3) Apr 03 2005 I think it's new. Can you post a short example?
- Derek Parnell (19/39) Apr 03 2005 What exactly do you mean by "and implements ElementOuter". At first, I
- Regan Heath (8/23) Apr 03 2005 So, if I'm understanding this, the error you get is "as if" you had:
- Ant (5/31) Apr 03 2005 yes.
- Regan Heath (15/52) Apr 03 2005 In which file is each class, eg.
- Derek Parnell (37/101) Apr 03 2005 Here is the code I tried to reproduce it with, but failed to.
- Ant (13/14) Apr 04 2005 [...]
(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implemented I have about 100 of these for 6 classes (the interface defines 5 methods) the compiler didn't complaint when all the classes were on the same module. Ant
Apr 03 2005
On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant wrote:(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implementedI assume you have CodeBlock defined along the lines of ... class CodeBlock : Block, ElementOuter { ... } The rule with D is, whenever you explicitly implement an interface, you must also explicitly implement all the functions named in that interface. So, only add 'ElementOuter' to the CodeBlock declaration if you are also going to define *all* the functions listed in that interface inside the CodeBlock class. So, even if you have defined getKnownTypes in Element or Block, and you put ElementOuter on the CodeBlock declaration, you still have to define getKnownTypes inside CodeBlock. -- Derek Melbourne, Australia 4/04/2005 12:14:01 PM
Apr 03 2005
In article <3qgutfatnci2$.15m6xzzml8kvx.dlg 40tude.net>, Derek Parnell says...On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant wrote:I know that what I have is "public class CodeBlock : Block {...}" (Just copied from above ;) It was fine when Block class was on the same module as the other 6 classes. Ant(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implementedI assume you have CodeBlock defined along the lines of ... class CodeBlock : Block, ElementOuter { ... } The rule with D is, whenever you explicitly implement an interface, you must also explicitly implement all the functions named in that interface. So, only add 'ElementOuter' to the CodeBlock declaration if you are also going to define *all* the functions listed in that interface inside the CodeBlock class. So, even if you have defined getKnownTypes in Element or Block, and you put ElementOuter on the CodeBlock declaration, you still have to define getKnownTypes inside CodeBlock.
Apr 03 2005
It was fine when Block class was on the same module as the other 6 classes.I think it's new. Can you post a short example?
Apr 03 2005
On Mon, 4 Apr 2005 03:35:50 +0000 (UTC), Ant wrote:In article <3qgutfatnci2$.15m6xzzml8kvx.dlg 40tude.net>, Derek Parnell says...What exactly do you mean by "and implements ElementOuter". At first, I thought you meant that Element implements ElementOuter. But when I did this I got no messages. It was only later when I read your sentence above as "CodeBlock extends Block, and Block both extends Element and implements ElementOuter" that I placed ElementOuter onto Block's definition and then I got the message. [snip]On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant wrote:(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation.I know that what I have is "public class CodeBlock : Block {...}" (Just copied from above ;) It was fine when Block class was on the same module as the other 6 classes.Ok, its just that when I tried to reproduce the message, the only way I could get it was to explicitly place ElementOuter on a class definition and *not* define the function body in that class. I guess this is a case where you will need to reduce it to the minimum code sample for Walter to investigate. ;-) -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v1.19 released 04/Apr/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 4/04/2005 1:54:03 PM
Apr 03 2005
On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implemented I have about 100 of these for 6 classes (the interface defines 5 methods) the compiler didn't complaint when all the classes were on the same module.So, if I'm understanding this, the error you get is "as if" you had: public class CodeBlock : Block, ElementOuter {...} right? I assume Block implements a getKnownTypes method? which should be inherited by CodeBlock. Regan
Apr 03 2005
In article <opsootyke123k2f5 nrage.netwin.co.nz>, Regan Heath says...On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:yes.(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implemented I have about 100 of these for 6 classes (the interface defines 5 methods) the compiler didn't complaint when all the classes were on the same module.So, if I'm understanding this, the error you get is "as if" you had: public class CodeBlock : Block, ElementOuter {...} right?I assume Block implements a getKnownTypes method? which should be inherited by CodeBlock.yes. It was fine when Block was defined on the same module as CodeBlock. Ant
Apr 03 2005
On Mon, 4 Apr 2005 03:33:30 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:In article <opsootyke123k2f5 nrage.netwin.co.nz>, Regan Heath says...In which file is each class, eg. [block.d] class Block.. [element.d] class Element.. [codeblock.d] class CodeBlock.. where is ElementOuter defined? I was going to try a stripped down version of the same thing myself. Have you tried that yet? If so, post it here and I'll try it and see if I can find anything probative. Regan p.s. So far it looks like a bug to me.On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:yes.(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implemented I have about 100 of these for 6 classes (the interface defines 5 methods) the compiler didn't complaint when all the classes were on the same module.So, if I'm understanding this, the error you get is "as if" you had: public class CodeBlock : Block, ElementOuter {...} right?I assume Block implements a getKnownTypes method? which should be inherited by CodeBlock.yes. It was fine when Block was defined on the same module as CodeBlock.
Apr 03 2005
On Mon, 04 Apr 2005 15:41:20 +1200, Regan Heath wrote:On Mon, 4 Apr 2005 03:33:30 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:Here is the code I tried to reproduce it with, but failed to. [ifc.d] module ifc; interface ElementOuter { int getKnownTypes(); } [elem.d] module elem; class Element{} [block.d] module block; private import elem; private import ifc; class Block : Element, ElementOuter { int getKnownTypes() { return 6;} } [codeblock.d] module codeblock; private import block; class CodeBlock : Block{} [test.d] module test; import codeblock; import std.stdio; void main() { CodeBlock A = new CodeBlock; writefln("%d", A.getKnownTypes()); } And this compiled fine and I got the output '6' printed. -- Derek Melbourne, Australia 4/04/2005 1:57:02 PMIn article <opsootyke123k2f5 nrage.netwin.co.nz>, Regan Heath says...In which file is each class, eg. [block.d] class Block.. [element.d] class Element.. [codeblock.d] class CodeBlock.. where is ElementOuter defined? I was going to try a stripped down version of the same thing myself. Have you tried that yet? If so, post it here and I'll try it and see if I can find anything probative. Regan p.s. So far it looks like a bug to me.On Mon, 4 Apr 2005 01:43:13 +0000 (UTC), Ant <Ant_member pathlink.com> wrote:yes.(of course an actual code example is right way to do this. I'm first asking if this is a known bug.) I had a bunch of classes on the same module because the old dmd (.80?) couldn't compile them any other way. Now I thought I would organize each on it's own module. my problem: CodeBlock extends Block that extends Element and implements ElementOuter. CodeBlock: "public class CodeBlock : Block {...}" i.e. doesn't declare ElementOuter reimplementation. and I got: parser/Module.d(32): class parser.Module.CodeBlock interface function ElementOuter.getKnownTypes isn't implemented I have about 100 of these for 6 classes (the interface defines 5 methods) the compiler didn't complaint when all the classes were on the same module.So, if I'm understanding this, the error you get is "as if" you had: public class CodeBlock : Block, ElementOuter {...} right?I assume Block implements a getKnownTypes method? which should be inherited by CodeBlock.yes. It was fine when Block was defined on the same module as CodeBlock.
Apr 03 2005
In article <1wk00ccnym94r.zspsdvvfu72p$.dlg 40tude.net>, Derek Parnell says...Here is the code I tried to reproduce it with, but failed to.[...] Yes, I tried the same thing with no problems. If it was easy to create the example I would have done just that. Anyway the entire thing has only about 20 modules it will not be impossible to strip that out. again, as on previous version of DMD, I will spend more time fighting the compiler then actually using it. I expected that when I started with D but it's kind of discouraging. This might be my fault and in that case we want to compiler to explain to me what I did wrong. I'll try to come up with a strip down version of my program. Ant
Apr 04 2005