www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module and package with the same name

reply "Francois Retief" <fgretief ieee.org> writes:
Hello,

I have a quick question about modules and packages?  Why can a module not 
have the same name as a packages in D?

I have the following directory/file structure in mind:

kernel/hal.d
kernel/hal/cpu.d
kernel/hal/cpu/arm.d
kernel/hal/cpu/arm/arm7tdmi.d
kernel/hal/cpu/arm/boards.d
kernel/hal/cpu/arm/boards/netarm.d
kernel/hal/cpu/sh4.d
kernel/hal/cpu/sh4/sh7750.d
kernel/hal/cpu/sh4/boards.d
kernel/hal/cpu/sh4/boards/dreamcast.d
etc ...

As I see it, packages are the directories, while modules are the files.  But 
when I try it, (DMD v0.149) I get:

#  hal.d: module hal and package hal have the same name.

Is this expected behaviour? If so, why this limitation?

Cheers
  Francois
--
Francois Retief
fgretief at ieee dot org
Mar 20 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Francois Retief" <fgretief ieee.org> wrote in message 
news:dvn6t3$uh9$1 digitaldaemon.com...
 #  hal.d: module hal and package hal have the same name.

 Is this expected behaviour?

Yes.
 If so, why this limitation?

For the same reason that this doesn't work: int S; struct S { ... } Name resolution should be scope dependent, not semantic dependent.
Mar 20 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Francois Retief" <fgretief ieee.org> wrote in message 
 news:dvn6t3$uh9$1 digitaldaemon.com...
 #  hal.d: module hal and package hal have the same name.

 Is this expected behaviour?

Yes.
 If so, why this limitation?

For the same reason that this doesn't work: int S; struct S { ... } Name resolution should be scope dependent, not semantic dependent.

(i.e., a module could contain other modules, like C++'s or C#'s namespaces) then we could have that behavior and the name resolution still be scope dependent. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dvujbc$1j5e$1 digitaldaemon.com...
 Indeed it should. However if the module were to also be the package, 
 (i.e., a module could contain other modules, like C++'s or C#'s 
 namespaces) then we could have that behavior and the name resolution still 
 be scope dependent.

You can do that now: --------------- module foo; import bar; import abc; -----------------
Mar 23 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

I think he means that this:

import foo;

And this:

import foo.bar;

Could work, if modules and packages were "the same thing."  So, 
"foo.func" would be a function in foo, and "foo.bar.func" would be a 
function in foo.bar.  Since, already, foo.bar doesn't necessarily mean 
anything semantic anyway.

At least, that's what I read.

-[Unknown]


 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dvujbc$1j5e$1 digitaldaemon.com...
 Indeed it should. However if the module were to also be the package, 
 (i.e., a module could contain other modules, like C++'s or C#'s 
 namespaces) then we could have that behavior and the name resolution still 
 be scope dependent.

You can do that now: --------------- module foo; import bar; import abc; -----------------

Mar 23 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Unknown W. Brackets wrote:
 Walter,
 
 I think he means that this:
 
 import foo;
 
 And this:
 
 import foo.bar;
 
 Could work, if modules and packages were "the same thing."  So, 
 "foo.func" would be a function in foo, and "foo.bar.func" would be a 
 function in foo.bar.  Since, already, foo.bar doesn't necessarily mean 
 anything semantic anyway.
 
 At least, that's what I read.
 
 -[Unknown]
 

Yup, that was it. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 26 2006