Thread overview | |||||
---|---|---|---|---|---|
|
October 10, 2005 module/template name collision | ||||
---|---|---|---|---|
| ||||
Hello! When I compile // Foo.d // => module Foo; (implicitly) interface Foo(T) {} // end - Foo.d // begin - Bar.d // => module Bar; (implicitly) import Foo; class Bar(T) : Foo!(T) {} int main() { alias Bar!(int[]) intBar; return 0; } // end - Bar.d I get the following error message (linux version of dmd.134): Bar.d(5): template instance Foo is not a template declaration, it is a import Bar.d(5): Foo!(int[]) is used as a type Bar.d(5): class Bar.Bar!(int[]).Bar base type must be class or interface, not void Bar.d(8): template instance Bar.Bar!(int[]) error instantiating So a collision between module and template name foo. I've two workarounds, but I don't like both of them: (1) explicitly set name of module Foo to (e.g.) foo (and adapt the import in Bar.d) (2) rename file Foo.d to foo.d (of course this implicitly sets the module name to foo) I don't like the first one, because I find it annoying to be forced to name the module explicitly artifical. And I'm not enthusiastic about the second one, cause AFAIR in java it is a must that a file and a contained class are named equally. What I find a bit strange about the whole thing, is that leaving out the template stuff, there are no error messages at all. This is at least a bit inconsistent, I think. Any proposals which way to go? Are there concrete naming conventions for files and modules? Best regards, Markus |
October 11, 2005 Re: module/template name collision | ||||
---|---|---|---|---|
| ||||
Posted in reply to markus_kranz | <markus_kranz@gmx.net> wrote in message news:dieof3$14ht$1@digitaldaemon.com... > Hello! > > When I compile > > // Foo.d > // => module Foo; (implicitly) > interface Foo(T) {} > // end - Foo.d > > // begin - Bar.d > // => module Bar; (implicitly) > import Foo; > > class Bar(T) : Foo!(T) {} > > int main() { > alias Bar!(int[]) intBar; > > return 0; > } > // end - Bar.d > > I get the following error message (linux version of dmd.134): > > Bar.d(5): template instance Foo is not a template declaration, it is a > import > Bar.d(5): Foo!(int[]) is used as a type > Bar.d(5): class Bar.Bar!(int[]).Bar base type must be class or interface, > not > void > Bar.d(8): template instance Bar.Bar!(int[]) error instantiating > > So a collision between module and template name foo. That is by design. > I've two workarounds, but I don't like both of them: > > (1) explicitly set name of module Foo to (e.g.) foo (and adapt the import > in > Bar.d) > (2) rename file Foo.d to foo.d (of course this implicitly sets the module > name > to foo) > > I don't like the first one, because I find it annoying to be forced to > name the > module explicitly artifical. And I'm not enthusiastic about the second > one, > cause AFAIR in java it is a must that a file and a contained class are > named > equally. > What I find a bit strange about the whole thing, is that leaving out the > template stuff, there are no error messages at all. This is at least a bit > inconsistent, I think. Why is it strange? D isn't Java. Given that the D style recommendation is to use lower case module names and caps class names there usually isn't a problem. See http://www.digitalmars.com/d/dstyle.html > Any proposals which way to go? > Are there concrete naming conventions for files and modules? > > Best regards, > Markus > > |
October 11, 2005 Re: module/template name collision | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | In article <difd8p$gml$1@digitaldaemon.com>, Ben Hinkle says... > ><markus_kranz@gmx.net> wrote in message news:dieof3$14ht$1@digitaldaemon.com... >> [snip] >> So a collision between module and template name foo. > >That is by design. Okay. >> I've two workarounds, but I don't like both of them: >> >> (1) explicitly set name of module Foo to (e.g.) foo (and adapt the import >> in >> Bar.d) >> (2) rename file Foo.d to foo.d (of course this implicitly sets the module >> name >> to foo) >> >> I don't like the first one, because I find it annoying to be forced to >> name the >> module explicitly artifical. And I'm not enthusiastic about the second >> one, >> cause AFAIR in java it is a must that a file and a contained class are >> named >> equally. >> What I find a bit strange about the whole thing, is that leaving out the >> template stuff, there are no error messages at all. This is at least a bit >> inconsistent, I think. > >Why is it strange? D isn't Java. Fortunately D isn't Java, but many people coming from Java are used to have a single class in each file and both named equally. Probably I've overlooked something, but I can't get why module names collide with template names, but not with class names. For example // Foo.d // => module Foo; (implicitly) interface Foo {} // end - Foo.d // begin - Bar.d // => module Bar; (implicitly) import Foo; class Bar : Foo {} int main() { alias Bar myBar; return 0; } // end - Bar.d works perfectly. When I decide later to generalize it using templates, suddenly I have to set module names explicitly (and adapt imports, of course). That's what I find a little bit strange. >Given that the D style recommendation is to use lower case module names and caps class names there usually isn't a problem. See http://www.digitalmars.com/d/dstyle.html At http://www.digitalmars.com/d/module.html one can find: "The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name." Your url provides the convention: "Module names are all lower case. This avoids problems dealing with case insensitive file systems." If you don't want to force developers to set module names explicitly, this implies the convention: 'File names are all lower case.' In the case that's your intention, perhaps this file naming convention could be added to the documentation. Otherwise (i.e. you want to force developers to set module names explicitly) I don't understand in which way a module naming convention interacts with case insensitive file systems. Best regards, Markus |
Copyright © 1999-2021 by the D Language Foundation