D - BUG or maybe not: forward reference again
Can/should we use the import "inside the class definition"? That solves the problem described here. Now that I wrote this, it all seams obvious. Maybe it could be explicit on the D modules page. here it is anyway: I had a few classes on the same source file that compiled with no problem. when I separated then into 1 file/class I get: ./parse/Class.d: class Class forward reference of base class Struct I double (triple) check in Class.d that the only ref I have to Struct is in "public class Class : Struct" (and the import) What might be happening (guessing, I didn't check to see how how the compiler does it) is: Struct imports Class because a struct can contain a class. Class imports Struct because a class is a struct. When Struct is parsed it finds import Class and gets it when parsing Class for the import on Struct it finds import Struct but knows that going to parse Struct would enter a loop so it quits giving a simple message. So to test this I moved all the imports into the classes, let me make sure that is clear: module parse.Struct; import parse.Element; public class Struct : Element { import parse.Enum; import parse.Function; import parse.Class; ... Class[] classes; } module parse.Class; import parse.Struct; public class Class : Struct { } So when module Class is parsed because of the import Class on the Struct class the compiler already knows that Struct is a class. (unfortunatly I also have a method named parse, so let me rename something...) Yes! That did it! So now back to my question: Can/should we use the import "inside the class definition"? the only import I'm leaving before the class definition is the import that contains the super class. Are the access modifiers (protected, private) respected on that case? (I guess I can do a simple test if nobody is sure about this) I know that imports cannot be used in a function body. (I just tried to import inside a function and got "./parseD/Parser.d(440): found 'import' instead of statement" from the compiler) Ant (I can already see the answer from Walter: A post with only one word, either 3 or 2 letters (yes or no) )
Dec 28 2003
On Sun, 28 Dec 2003 04:29:39 -0500, Ant wrote:Can/should we use the import "inside the class definition"?I'm very happy with that idea I hope it's 'legal' in D. Walter, I'm going to commit to this (i.e. change many source code files) can you confirm that this will not be dropped? thanks.Are the access modifiers (protected, private) respected on that case? (I guess I can do a simple test if nobody is sure about this)here it is the first test, 1 source file 2 classes: class A { private import std.string; void a() { printf("A test toString for 1 = %.*s\n",std.string.toString(1)); } } class B : A { void b() { printf("B test toString for 1 = %.*s\n",std.string.toString(1)); } } void main() { printf("main\n"); A a = new A; a.a(); B b = new B; b.b(); } it compiles. if B is not a subclass of A the compilation fails with: "Imp.d(15): undefined identifier std" note that "private" is not respected... TODO: same thing with to source files one for class A one for class B. output: main A test toString for 1 = 1 B test toString for 1 = 1 Ant
Dec 28 2003
On Sun, 28 Dec 2003 19:20:18 -0500, Ant wrote:TODO: same thing with to source files one for class A one for class B.here it is: class A { private import std.string; void a() { printf("A.a std.string.toString(1)== %.*s\n",std.string.toString(1)); } } private import ImpA; class B : A { void b() { printf("B.b std.string.toString(2)== %.*s\n",std.string.toString(2)); } } void main() { B b = new B; b.b(); } compiles OK (shouldn't because of the private import (?) compilation fails if B is not a subclass of A with: "ImpB.d(7): undefined identifier std" output B.b std.string.toString(2)== 2 Ant
Dec 28 2003