I can have three files:

main.d:
---
module one;

import two;
import lala.la;

void main() {
   foo();
   bar();
}
---

other.d
---
module two;

import std.stdio;

void foo() {
   writefln("Hello!");
}
---

dir/some_other.d
---
module lala.la;

import std.stdio;

void bar() {
   writefln("Hello!!");
}
---

and compile them with no problem:
dmd main.d other.d dir/some_other.d

Shouldn't the compiler say "Wait, you are saying that module one is in file main.d, module two is in other.d and module lala.la is in dir/some_other.d, this isn't quite well"? In http://www.digitalmars.com/d/module.html it states:

"The packages correspond to directory names in the source file path."
"The module name is the file name with the path and extension stripped off."

Why this isn't honored by the compiler?

My worry is, if this is valid, then in an IDE you can't just assume directories are packages, and filenames (path and extension stripped off) are modules, since this is not mandatory. Then it's a lot harder to do. Further, it complicates things since probably nobody wants to name a module with a name and path that dosen't match the underlying filesystem's name and path. So enforcing this in a compiler eliminates "bugs".

Ary Manzana wrote

> In http://www.digitalmars.com/d/module.html it states:

| 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.

Please read carefully.

-manfred

Manfred Nowak escribió:
> Ary Manzana wrote
> 
>> In http://www.digitalmars.com/d/module.html it states:
> 
> | 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.
> 
> Please read carefully.

So what's the point of settings a package and module name different than what's in the filesystem?

Ary Manzana wrote:
> Manfred Nowak escribió:
>> Ary Manzana wrote
>>
>>> In http://www.digitalmars.com/d/module.html it states:
>>
>> | 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.
>>
>> Please read carefully.
> 
> So what's the point of settings a package and module name different than what's in the filesystem?

Its useful as an alternative means of doing platform-versioning.  (At least I remember this working... I might just be crazy.)  For example:

Given project:
main.d - module main;
util_win32.d - module util;
util_linux.d - module util;

You may now simply `import util;` in main, and on the command line pass the appropriate util module.  I'm sure there might be another use as well, but I admit that even this one has limited value -- aside from avoiding having a redundant version(){}else{} block at the beginning of all modules importing util, but we have two different ways of avoiding that: a go-between module with a version'd public import of util, or a mixin.  (Possibly even a mixin(import()).)

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls escribió:
> Ary Manzana wrote:
>> Manfred Nowak escribió:
>>> Ary Manzana wrote
>>>
>>>> In http://www.digitalmars.com/d/module.html it states:
>>>
>>> | 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.
>>>
>>> Please read carefully.
>>
>> So what's the point of settings a package and module name different than what's in the filesystem?
> 
> Its useful as an alternative means of doing platform-versioning.

Why use an alternative of the built-in version system?

Also, if you have many versioned modules (a1_win32.d, a1_linux.d, b1_win32.d, b1_linux.d, etc.) you need to change the command line for each of the modules, instead of just changing the version passed. You also have to tell the other developers: remember not to use the version flag, but to change the suffix of the filenames according to the version...

Maybe doing the suffix thing is valid for C or C++, but I think D tries to solve that using versions, and not using them seems awkward to me.

Ary Manzana wrote

> Why use an alternative of the built-in version system?

The version system is not equivalent to the module naming system.

-manfred

Manfred Nowak escribió:
> Ary Manzana wrote
> 
>> Why use an alternative of the built-in version system?
> 
> The version system is not equivalent to the module naming system.

Ok. My point is that it is totaly unnecessary to have the module declaration say something different than it's location relative to the include source path. This is like things work in Java, for example: you get an error if the package declaration and the filesystem dosen't match. Why not apply the same in D?

Ary Manzana wrote:
> Manfred Nowak escribió:
>> Ary Manzana wrote
>>
>>> Why use an alternative of the built-in version system?
>>
>> The version system is not equivalent to the module naming system.
> 
> Ok. My point is that it is totaly unnecessary to have the module declaration say something different than it's location relative to the include source path. This is like things work in Java, for example: you get an error if the package declaration and the filesystem dosen't match. Why not apply the same in D?

I plan to use this while DDL is out of commission.

For instance: I have a class engine.gx.camera.Camera, which is just the interface declaration (no actual contents).  I then have two different implementations: one for GL and one for D3D; they both need to have the same module name, but they exist in totally different places on the physical filesystem.

And don't say "just use version()s" since I really don't want to have to go around putting in version flags in every place this switch happens. I just want to do it once at compile time and be done with it.

Hell, once DDL is working again, they won't even be linked together at all.  The whole point of this is to allow someone to swap out which implementation to use at run time; version()s won't let you do that :)

Besides, I don't see that this is a huge problem.  IDEs can just assume the "normal" behaviour holds, and if they find it doesn't they can either ignore it, or flag the modules in question for having odd names.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Ary Manzana wrote

> totaly unnecessary to have the module declaration
> say something different

Can you prove this statement correct?
Why then have module declarations at all? What is the redundany good
for?

In general: any proof that some form of existing freedom is not usable is a counter argument for the wish to delete that freedom. For a freedom that is usable a declaration of unnecessity is insufficient; a retraction has to be grounded by greater wealth (in terms of money) of the set of possible users---unless it is a "political" decision.

-manfred

On Sun, 13 May 2007 05:22:15 +0000 (UTC), Manfred Nowak wrote:

> Ary Manzana wrote
> 
>> totaly unnecessary to have the module declaration
>> say something different
> 
> Can you prove this statement correct?
> Why then have module declarations at all? What is the redundany good
> for?
> 
> In general: any proof that some form of existing freedom is not usable is a counter argument for the wish to delete that freedom. For a freedom that is usable a declaration of unnecessity is insufficient; a retraction has to be grounded by greater wealth (in terms of money) of the set of possible users---unless it is a "political" decision.

The only reason I can see as the purpose of the module statement is to ensure that one has named the file as one intended it to be named.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell