Thread overview
inconsistent module name not rejected by dmd
Jan 26, 2005
zwang
Jan 26, 2005
Ben Hinkle
Jan 27, 2005
Stewart Gordon
Jan 27, 2005
J C Calvarese
Jan 27, 2005
Ben Hinkle
January 26, 2005
<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>
January 26, 2005
"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.


January 27, 2005
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.
January 27, 2005
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
January 27, 2005
"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/packages.doc.html#37758). 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.