www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - inconsistent module name not rejected by dmd

reply zwang <nehzgnaw gmail.com> writes:
<doc>
Modules have a one-to-one correspondence with source files. The module 
name is the file name with the path and extension stripped off.
</doc>

So the following code should not compile:

<code>
//file: test.d
module nul;
</code>
Jan 26 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"zwang" <nehzgnaw gmail.com> wrote in message 
news:ct8k57$27ut$1 digitaldaemon.com...
 <doc>
 Modules have a one-to-one correspondence with source files. The module 
 name is the file name with the path and extension stripped off.
 </doc>

 So the following code should not compile:

 <code>
 //file: test.d
 module nul;
 </code>
A little lower down the doc says <doc> 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. </doc> The sentance you quoted should be modified or removed.
Jan 26 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ben Hinkle wrote:
<snip>
 A little lower down the doc says
 <doc>
 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.
 </doc>
 
 The sentance you quoted should be modified or removed. 
How is the compiler supposed to find a module if its name has been changed from the source file name? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 27 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
In article <ctb8kv$2lhq$1 digitaldaemon.com>, Stewart Gordon says...
Ben Hinkle wrote:
<snip>
 A little lower down the doc says
 <doc>
 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.
 </doc>
 
 The sentance you quoted should be modified or removed. 
How is the compiler supposed to find a module if its name has been changed from the source file name?
I'd think it'd work if you added the renamed module at the command line. Perhaps? If that doesn't work, I don't know what would work. Sounds like this feature is more trouble than it's worth. Maybe it should just be made an error if the module name doesn't match the filename. And then update the spec to reflect this new rule.
Stewart.
jcc7
Jan 27 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message 
news:ctbb6f$2pl3$1 digitaldaemon.com...
 In article <ctb8kv$2lhq$1 digitaldaemon.com>, Stewart Gordon says...
Ben Hinkle wrote:
<snip>
 A little lower down the doc says
 <doc>
 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.
 </doc>

 The sentance you quoted should be modified or removed.
How is the compiler supposed to find a module if its name has been changed from the source file name?
I'd think it'd work if you added the renamed module at the command line. Perhaps? If that doesn't work, I don't know what would work.
yes - as the OP's examples showed. If you put all the file in the same dmd command the compiler never has to go looking on the file system for any imports. The compiler first loops over all source files on the command line and open and parse the files. This is when it looks for module declarations(the "parse" phase). Only after that does it start looking for import declarations and search for modules it doesn't already know about (the "semantics" phase).
 Sounds like this feature is more trouble than it's worth. Maybe it should 
 just
 be made an error if the module name doesn't match the filename. And then 
 update
 the spec to reflect this new rule.
The Java language spec has some reasons for why Java does this (see http://java.sun.com/docs/books/jls/second_edition/html/packa One reason is that it allows the compiler to work on systems with some other mechanism besides a file system (eg a database of modules) - or work with file names that aren't identifiers. These situations might seem a bit unusual but in everyday use I find it nice to have the full package and module name at the top of the module. Otherwise you have to find that info elsewhere either by searching the file system for the file or by writing the full path on printouts etc. It's handy to have the hierarchy right there in the source code.
Jan 27 2005