Thread overview
Module and package with the same name
Mar 20, 2006
Francois Retief
Mar 20, 2006
Walter Bright
Mar 23, 2006
Bruno Medeiros
Mar 24, 2006
Walter Bright
Mar 26, 2006
Bruno Medeiros
March 20, 2006
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


March 20, 2006
"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.


March 23, 2006
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.
> 
> 
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.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
March 24, 2006
"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;
----------------- 


March 24, 2006
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;
> ----------------- 
> 
> 
March 26, 2006
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