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