Thinking about all this i came to a conclusion that things aren't that simple, but then i thought why not?

The need for package level access is something most poeple agree
on, and having all files in a package be friends is a good start, but
here i propose a way to restrict this access in a way that each
module decides who it want's to be friend with :)

I will start with the example: By definition all modules in the "std"
would be friends.
for example
std/stream.d:    module std.stream; //is a friend to everyone in std
std/stream.d;    module stream; //it is still std.stream but it isn't a
//friend to anyone else in std

And another example:
If Arcane Jill puts a bigint

etc/bigint/bigint.d        //module bigint.bigint;

//it is afriend to all other modules in bigint (like prime.d) but
//not to any in etc

etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd //is a friend to all modules in bigint.

but you could also if you want do something like: etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd //now it is a friend only to all modules in bigint_files dir

I know this this is probbably VERY stupid, and now i'm
waiting for someone to tell me why :) :)


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9vkin$2n9q$1@digitaldaemon.com...
> I definitely endorse the call for package level access, but the question
"what
> is a package?" needs clarification before that can happen. Now, I know
that
> "package" is defined as "directory" in the docs, but when we ask for package-level access, I don't think we are exactly asking for
directory-level
> access. I certainly am not. Let me show you what I mean.
>
> My directory structure is currently as follows:
>
> etc\random.d
> etc\random_files\*.d
> etc\random_files\entropy\*.d
> etc\random_files\prbg\*d
>
> (As I've mentioned before I would prefer that I was allowed to have:
>
> etc\random.d
> etc\random\*.d
> etc\random\entropy\*.d
> etc\random\prbg\*d
>
> but the compiler annoyingly rejects that. Sorry dude - can't have a
directory
> with the same name and in the same directory as a .d file, no way. I hope
this
> is fixed, one day, but it's only an annoyance, not a show-stopper, so I
guess I
> can live with it for now).
>
> Anyway, the point is that, as I far as I am concerned, this entire
heirarchy is
> all part of the same package. For example,
"etc.random_files.entropy.noise" and
> "etc.random_files.prbg.forward_secure" are *friends*, and need access to
each
> other's "package level" functions.
>
> And so I have a suggestion as to how this might work.
>
> SUGGESTION 1:
>
> The suggestion is that we define which package a module is in, right at
the
> start of the file. Like this:
>
> -----------------------------------------------
> >       module etc.random_files.entropy.noise;
> >       package etc.random_files;
> >       import whatever;
>
> -----------------------------------------------
> >       module etc.random_files.entropy.noise;
> >       package etc.random_files;
> >       import whatever;
>
> It would be a compile error if the package name were not an ancestor of
the
> module name.
>
> Now, with this system in force, I could then declare:
>
> >       package class MyClass
> >       {
> >       }
>
> and have that class visible everywhere within my directory tree, but
visible
> nowhere else.
>
> This suggestion mandates that a module can be in precisely one package and
no
> other, which may not be suitable for all situations, so I also have a
second
> suggestion (mutually contradictory with the first) which may be better for
some
> people.
>
> SUGGESTION 2:
>
> Instead of putting a package directive at the top of the file, we specify
it
> instead in the declaration, like this:
>
> >       package(etc.random_files) class MyClass
> >       {
> >       }
>
> Bingo! I've just declared that MyClass is visible anywhere in the
directory
> structure at or below etc.random_files, and nowhere else.
>
> Personally, I think that suggestion 2 is better than suggestion 1,
although
> suggestion 2 makes for cleaner source code.
>
> Arcane Jill
>
>

On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji <ivan.senji@public.srce.hr> wrote:
> Thinking about all this i came to a conclusion that things aren't
> that simple, but then i thought why not?
>
> The need for package level access is something most poeple agree
> on, and having all files in a package be friends is a good start, but
> here i propose a way to restrict this access in a way that each
> module decides who it want's to be friend with :)
>
> I will start with the example: By definition all modules in the "std"
> would be friends.
> for example
> std/stream.d:    module std.stream; //is a friend to everyone in std
> std/stream.d;    module stream; //it is still std.stream but it isn't a
> //friend to anyone else in std
>
> And another example:
> If Arcane Jill puts a bigint
>
> etc/bigint/bigint.d        //module bigint.bigint;
>
> //it is afriend to all other modules in bigint (like prime.d) but
> //not to any in etc
>
> etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd
> //is a friend to all modules in bigint.
>
> but you could also if you want do something like:
> etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd
> //now it is a friend only to all modules in bigint_files dir
>
> I know this this is probbably VERY stupid, and now i'm
> waiting for someone to tell me why :) :)

Well, I'm not sure but I think the module def at the top of the file is actually more important to the compiler than where the file is, so changing it from "module std.stream" to "module stream" means "import std.stream" will no longer work. I could be wrong.

My experience with modules seems to indicate to me that it doesn't matter where the file is actually stored so long as the module defs are correct in the file and then in the import line.

This seemed weird at first.. and still seems weird to me.

> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
> news:c9vkin$2n9q$1@digitaldaemon.com...
>> I definitely endorse the call for package level access, but the question
> "what
>> is a package?" needs clarification before that can happen. Now, I know
> that
>> "package" is defined as "directory" in the docs, but when we ask for
>> package-level access, I don't think we are exactly asking for
> directory-level
>> access. I certainly am not. Let me show you what I mean.
>>
>> My directory structure is currently as follows:
>>
>> etc\random.d
>> etc\random_files\*.d
>> etc\random_files\entropy\*.d
>> etc\random_files\prbg\*d
>>
>> (As I've mentioned before I would prefer that I was allowed to have:
>>
>> etc\random.d
>> etc\random\*.d
>> etc\random\entropy\*.d
>> etc\random\prbg\*d
>>
>> but the compiler annoyingly rejects that. Sorry dude - can't have a
> directory
>> with the same name and in the same directory as a .d file, no way. I hope
> this
>> is fixed, one day, but it's only an annoyance, not a show-stopper, so I
> guess I
>> can live with it for now).
>>
>> Anyway, the point is that, as I far as I am concerned, this entire
> heirarchy is
>> all part of the same package. For example,
> "etc.random_files.entropy.noise" and
>> "etc.random_files.prbg.forward_secure" are *friends*, and need access to
> each
>> other's "package level" functions.
>>
>> And so I have a suggestion as to how this might work.
>>
>> SUGGESTION 1:
>>
>> The suggestion is that we define which package a module is in, right at
> the
>> start of the file. Like this:
>>
>> -----------------------------------------------
>> >       module etc.random_files.entropy.noise;
>> >       package etc.random_files;
>> >       import whatever;
>>
>> -----------------------------------------------
>> >       module etc.random_files.entropy.noise;
>> >       package etc.random_files;
>> >       import whatever;
>>
>> It would be a compile error if the package name were not an ancestor of
> the
>> module name.
>>
>> Now, with this system in force, I could then declare:
>>
>> >       package class MyClass
>> >       {
>> >       }
>>
>> and have that class visible everywhere within my directory tree, but
> visible
>> nowhere else.
>>
>> This suggestion mandates that a module can be in precisely one package and
> no
>> other, which may not be suitable for all situations, so I also have a
> second
>> suggestion (mutually contradictory with the first) which may be better for
> some
>> people.
>>
>> SUGGESTION 2:
>>
>> Instead of putting a package directive at the top of the file, we specify
> it
>> instead in the declaration, like this:
>>
>> >       package(etc.random_files) class MyClass
>> >       {
>> >       }
>>
>> Bingo! I've just declared that MyClass is visible anywhere in the
> directory
>> structure at or below etc.random_files, and nowhere else.
>>
>> Personally, I think that suggestion 2 is better than suggestion 1,
> although
>> suggestion 2 makes for cleaner source code.
>>
>> Arcane Jill
>>
>>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr8702tr25a2sq9@digitalmars.com...
> On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji <ivan.senji@public.srce.hr> wrote:
> > Thinking about all this i came to a conclusion that things aren't that simple, but then i thought why not?
> >
> > The need for package level access is something most poeple agree
> > on, and having all files in a package be friends is a good start, but
> > here i propose a way to restrict this access in a way that each
> > module decides who it want's to be friend with :)
> >
> > I will start with the example: By definition all modules in the "std"
> > would be friends.
> > for example
> > std/stream.d:    module std.stream; //is a friend to everyone in std
> > std/stream.d;    module stream; //it is still std.stream but it isn't a
> > //friend to anyone else in std
> >
> > And another example:
> > If Arcane Jill puts a bigint
> >
> > etc/bigint/bigint.d        //module bigint.bigint;
> >
> > //it is afriend to all other modules in bigint (like prime.d) but
> > //not to any in etc
> >
> > etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd //is a friend to all modules in bigint.
> >
> > but you could also if you want do something like: etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd //now it is a friend only to all modules in bigint_files dir
> >
> > I know this this is probbably VERY stupid, and now i'm
> > waiting for someone to tell me why :) :)
>
> Well, I'm not sure but I think the module def at the top of the file is actually more important to the compiler than where the file is, so changing it from "module std.stream" to "module stream" means "import std.stream" will no longer work. I could be wrong.

Did you really think i didn't try it before posting? :)
It DOES work.

Change in std/stream.d
module std.stream;
to module stream;

And import it the usual way:
import std.stream;

and everything works as usual, why not give the other definition  a new meaning :)

> My experience with modules seems to indicate to me that it doesn't matter where the file is actually stored so long as the module defs are correct in the file and then in the import line.
>
> This seemed weird at first.. and still seems weird to me.

To me too, but i'm slowlly getting used to it!

> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9vkin$2n9q$1@digitaldaemon.com...
> >> I definitely endorse the call for package level access, but the
question
> > "what
> >> is a package?" needs clarification before that can happen. Now, I know
> > that
> >> "package" is defined as "directory" in the docs, but when we ask for package-level access, I don't think we are exactly asking for
> > directory-level
> >> access. I certainly am not. Let me show you what I mean.
> >>
> >> My directory structure is currently as follows:
> >>
> >> etc\random.d
> >> etc\random_files\*.d
> >> etc\random_files\entropy\*.d
> >> etc\random_files\prbg\*d
> >>
> >> (As I've mentioned before I would prefer that I was allowed to have:
> >>
> >> etc\random.d
> >> etc\random\*.d
> >> etc\random\entropy\*.d
> >> etc\random\prbg\*d
> >>
> >> but the compiler annoyingly rejects that. Sorry dude - can't have a
> > directory
> >> with the same name and in the same directory as a .d file, no way. I hope
> > this
> >> is fixed, one day, but it's only an annoyance, not a show-stopper, so I
> > guess I
> >> can live with it for now).
> >>
> >> Anyway, the point is that, as I far as I am concerned, this entire
> > heirarchy is
> >> all part of the same package. For example,
> > "etc.random_files.entropy.noise" and
> >> "etc.random_files.prbg.forward_secure" are *friends*, and need access
to
> > each
> >> other's "package level" functions.
> >>
> >> And so I have a suggestion as to how this might work.
> >>
> >> SUGGESTION 1:
> >>
> >> The suggestion is that we define which package a module is in, right at
> > the
> >> start of the file. Like this:
> >>
> >> -----------------------------------------------
> >> >       module etc.random_files.entropy.noise;
> >> >       package etc.random_files;
> >> >       import whatever;
> >>
> >> -----------------------------------------------
> >> >       module etc.random_files.entropy.noise;
> >> >       package etc.random_files;
> >> >       import whatever;
> >>
> >> It would be a compile error if the package name were not an ancestor of
> > the
> >> module name.
> >>
> >> Now, with this system in force, I could then declare:
> >>
> >> >       package class MyClass
> >> >       {
> >> >       }
> >>
> >> and have that class visible everywhere within my directory tree, but
> > visible
> >> nowhere else.
> >>
> >> This suggestion mandates that a module can be in precisely one package and
> > no
> >> other, which may not be suitable for all situations, so I also have a
> > second
> >> suggestion (mutually contradictory with the first) which may be better
> >> for
> > some
> >> people.
> >>
> >> SUGGESTION 2:
> >>
> >> Instead of putting a package directive at the top of the file, we specify
> > it
> >> instead in the declaration, like this:
> >>
> >> >       package(etc.random_files) class MyClass
> >> >       {
> >> >       }
> >>
> >> Bingo! I've just declared that MyClass is visible anywhere in the
> > directory
> >> structure at or below etc.random_files, and nowhere else.
> >>
> >> Personally, I think that suggestion 2 is better than suggestion 1,
> > although
> >> suggestion 2 makes for cleaner source code.
> >>
> >> Arcane Jill
> >>
> >>
> >
> >
>
>
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji@public.srce.hr> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opr8702tr25a2sq9@digitalmars.com...
>> On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji <ivan.senji@public.srce.hr>
>> wrote:
>> > Thinking about all this i came to a conclusion that things aren't
>> > that simple, but then i thought why not?
>> >
>> > The need for package level access is something most poeple agree
>> > on, and having all files in a package be friends is a good start, but
>> > here i propose a way to restrict this access in a way that each
>> > module decides who it want's to be friend with :)
>> >
>> > I will start with the example: By definition all modules in the "std"
>> > would be friends.
>> > for example
>> > std/stream.d:    module std.stream; //is a friend to everyone in std
>> > std/stream.d;    module stream; //it is still std.stream but it isn't 
>> a
>> > //friend to anyone else in std
>> >
>> > And another example:
>> > If Arcane Jill puts a bigint
>> >
>> > etc/bigint/bigint.d        //module bigint.bigint;
>> >
>> > //it is afriend to all other modules in bigint (like prime.d) but
>> > //not to any in etc
>> >
>> > etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd
>> > //is a friend to all modules in bigint.
>> >
>> > but you could also if you want do something like:
>> > etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd
>> > //now it is a friend only to all modules in bigint_files dir
>> >
>> > I know this this is probbably VERY stupid, and now i'm
>> > waiting for someone to tell me why :) :)
>>
>> Well, I'm not sure but I think the module def at the top of the file is
>> actually more important to the compiler than where the file is, so
>> changing it from "module std.stream" to "module stream" means "import
>> std.stream" will no longer work. I could be wrong.
>
> Did you really think i didn't try it before posting? :)
> It DOES work.

Then what have I done wrong...

[d:\d\src\a\main.d]
import bbb.abc;
import ccc.def;

void main() {
	foo(5);
	bar(7);
}

[d:\d\src\a\bbb\abc.d]
module bbb.abc;

int foo(int a) {
	return a;
}

[d:d\src\a\ccc\def.d]
//module ccc.def;
module def;

int bar(int a) {
	return a;
}

D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt
main.d(2): module def is in multiple packages def

?

> Change in std/stream.d
> module std.stream;
> to module stream;
>
> And import it the usual way:
> import std.stream;
>
> and everything works as usual, why not give the other
> definition  a new meaning :)

My gut feeling is that it's a bit weird. But like I said before modules and imports still seem a bit weird to me, how the file doesn't have to be in the 'right' directory...

>> My experience with modules seems to indicate to me that it doesn't matter
>> where the file is actually stored so long as the module defs are correct
>> in the file and then in the import line.
>>
>> This seemed weird at first.. and still seems weird to me.
>
> To me too, but i'm slowlly getting used to it!
>
>> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
>> > news:c9vkin$2n9q$1@digitaldaemon.com...
>> >> I definitely endorse the call for package level access, but the
> question
>> > "what
>> >> is a package?" needs clarification before that can happen. Now, I 
>> know
>> > that
>> >> "package" is defined as "directory" in the docs, but when we ask for
>> >> package-level access, I don't think we are exactly asking for
>> > directory-level
>> >> access. I certainly am not. Let me show you what I mean.
>> >>
>> >> My directory structure is currently as follows:
>> >>
>> >> etc\random.d
>> >> etc\random_files\*.d
>> >> etc\random_files\entropy\*.d
>> >> etc\random_files\prbg\*d
>> >>
>> >> (As I've mentioned before I would prefer that I was allowed to have:
>> >>
>> >> etc\random.d
>> >> etc\random\*.d
>> >> etc\random\entropy\*.d
>> >> etc\random\prbg\*d
>> >>
>> >> but the compiler annoyingly rejects that. Sorry dude - can't have a
>> > directory
>> >> with the same name and in the same directory as a .d file, no way. I
>> >> hope
>> > this
>> >> is fixed, one day, but it's only an annoyance, not a show-stopper, 
>> so I
>> > guess I
>> >> can live with it for now).
>> >>
>> >> Anyway, the point is that, as I far as I am concerned, this entire
>> > heirarchy is
>> >> all part of the same package. For example,
>> > "etc.random_files.entropy.noise" and
>> >> "etc.random_files.prbg.forward_secure" are *friends*, and need access
> to
>> > each
>> >> other's "package level" functions.
>> >>
>> >> And so I have a suggestion as to how this might work.
>> >>
>> >> SUGGESTION 1:
>> >>
>> >> The suggestion is that we define which package a module is in, right 
>> at
>> > the
>> >> start of the file. Like this:
>> >>
>> >> -----------------------------------------------
>> >> >       module etc.random_files.entropy.noise;
>> >> >       package etc.random_files;
>> >> >       import whatever;
>> >>
>> >> -----------------------------------------------
>> >> >       module etc.random_files.entropy.noise;
>> >> >       package etc.random_files;
>> >> >       import whatever;
>> >>
>> >> It would be a compile error if the package name were not an ancestor 
>> of
>> > the
>> >> module name.
>> >>
>> >> Now, with this system in force, I could then declare:
>> >>
>> >> >       package class MyClass
>> >> >       {
>> >> >       }
>> >>
>> >> and have that class visible everywhere within my directory tree, but
>> > visible
>> >> nowhere else.
>> >>
>> >> This suggestion mandates that a module can be in precisely one 
>> package
>> >> and
>> > no
>> >> other, which may not be suitable for all situations, so I also have a
>> > second
>> >> suggestion (mutually contradictory with the first) which may be 
>> better
>> >> for
>> > some
>> >> people.
>> >>
>> >> SUGGESTION 2:
>> >>
>> >> Instead of putting a package directive at the top of the file, we
>> >> specify
>> > it
>> >> instead in the declaration, like this:
>> >>
>> >> >       package(etc.random_files) class MyClass
>> >> >       {
>> >> >       }
>> >>
>> >> Bingo! I've just declared that MyClass is visible anywhere in the
>> > directory
>> >> structure at or below etc.random_files, and nowhere else.
>> >>
>> >> Personally, I think that suggestion 2 is better than suggestion 1,
>> > although
>> >> suggestion 2 makes for cleaner source code.
>> >>
>> >> Arcane Jill
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr873j1yl5a2sq9@digitalmars.com...
> On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji@public.srce.hr> wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>
> Then what have I done wrong...
>
> [d:\d\src\a\main.d]
> import bbb.abc;
> import ccc.def;
>
> void main() {
> foo(5);
> bar(7);
> }
>
> [d:\d\src\a\bbb\abc.d]
> module bbb.abc;
>
> int foo(int a) {
> return a;
> }
>
> [d:d\src\a\ccc\def.d]
> //module ccc.def;
> module def;
>
> int bar(int a) {
> return a;
> }
>
> D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt main.d(2): module def is in multiple packages def
>
> ?

Yes, you are right! I tried only with std.stream, and not with my own modules. But to tell you do truth i don't really understand  that error message. What two packages is module def in? I think the compiler is being confused, but it shouldn't get confused by this, or maybe should, i know nothing anymore :)

You should use "private import".



Ivan Senji wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opr873j1yl5a2sq9@digitalmars.com...
> 
>>D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt
>>main.d(2): module def is in multiple packages def
>>
>>?
> 
> 
> Yes, you are right! I tried only with std.stream, and not with
> my own modules. But to tell you do truth i don't really
> understand  that error message. What two packages is module def
> in? I think the compiler is being confused, but it shouldn't get
> confused by this, or maybe should, i know nothing anymore :)


-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/

Actually, C# uses another keyword "internal" which works like "public" inside the assembly and "private" for all other files.


Arcane Jill wrote:

> I definitely endorse the call for package level access, but the question "what
> is a package?" needs clarification before that can happen. Now, I know that
> "package" is defined as "directory" in the docs, but when we ask for
> package-level access, I don't think we are exactly asking for directory-level
> access. I certainly am not. Let me show you what I mean.
> 
> My directory structure is currently as follows:
> 
> etc\random.d
> etc\random_files\*.d
> etc\random_files\entropy\*.d
> etc\random_files\prbg\*d
> 
> (As I've mentioned before I would prefer that I was allowed to have:
> 
> etc\random.d
> etc\random\*.d
> etc\random\entropy\*.d
> etc\random\prbg\*d
> 
> but the compiler annoyingly rejects that. Sorry dude - can't have a directory
> with the same name and in the same directory as a .d file, no way. I hope this
> is fixed, one day, but it's only an annoyance, not a show-stopper, so I guess I
> can live with it for now).
> 
> Anyway, the point is that, as I far as I am concerned, this entire heirarchy is
> all part of the same package. For example, "etc.random_files.entropy.noise" and
> "etc.random_files.prbg.forward_secure" are *friends*, and need access to each
> other's "package level" functions.
> 
> And so I have a suggestion as to how this might work.
> 
> SUGGESTION 1:
> 
> The suggestion is that we define which package a module is in, right at the
> start of the file. Like this:
> 
> -----------------------------------------------
> 
>>      module etc.random_files.entropy.noise;
>>      package etc.random_files;
>>      import whatever;
> 
> 
> -----------------------------------------------
> 
>>      module etc.random_files.entropy.noise;
>>      package etc.random_files;
>>      import whatever;
> 
> 
> It would be a compile error if the package name were not an ancestor of the
> module name.
> 
> Now, with this system in force, I could then declare:
> 
> 
>>      package class MyClass
>>      {
>>      }
> 
> 
> and have that class visible everywhere within my directory tree, but visible
> nowhere else.
> 
> This suggestion mandates that a module can be in precisely one package and no
> other, which may not be suitable for all situations, so I also have a second
> suggestion (mutually contradictory with the first) which may be better for some
> people.
> 
> SUGGESTION 2:
> 
> Instead of putting a package directive at the top of the file, we specify it
> instead in the declaration, like this:
> 
> 
>>      package(etc.random_files) class MyClass
>>      {
>>      }
> 
> 
> Bingo! I've just declared that MyClass is visible anywhere in the directory
> structure at or below etc.random_files, and nowhere else.
> 
> Personally, I think that suggestion 2 is better than suggestion 1, although
> suggestion 2 makes for cleaner source code.
> 
> Arcane Jill
> 
> 


-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------

I tried private import but it doesn't change anything, still the same error message.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:ca24ht$d0s$1@digitaldaemon.com...
> You should use "private import".
>
>
>
> Ivan Senji wrote:
>
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opr873j1yl5a2sq9@digitalmars.com...
> >
> >>D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt main.d(2): module def is in multiple packages def
> >>
> >>?
> >
> >
> > Yes, you are right! I tried only with std.stream, and not with my own modules. But to tell you do truth i don't really understand  that error message. What two packages is module def in? I think the compiler is being confused, but it shouldn't get confused by this, or maybe should, i know nothing anymore :)
>
>
> --
> Julio César Carrascal Urquijo
> http://jcesar.f2o.org/

On Mon, 07 Jun 2004 23:58:39 +1200, Regan Heath wrote:

> On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji@public.srce.hr> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opr8702tr25a2sq9@digitalmars.com...
>>> On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji
>>> <ivan.senji@public.srce.hr>
>>> wrote:
>>> > Thinking about all this i came to a conclusion that things aren't that simple, but then i thought why not?
>>> >
>>> > The need for package level access is something most poeple agree
>>> > on, and having all files in a package be friends is a good start, but
>>> > here i propose a way to restrict this access in a way that each
>>> > module decides who it want's to be friend with :)
>>> >
>>> > I will start with the example: By definition all modules in the "std"
>>> > would be friends.
>>> > for example
>>> > std/stream.d:    module std.stream; //is a friend to everyone in std
>>> > std/stream.d;    module stream; //it is still std.stream but it isn't
>>> a
>>> > //friend to anyone else in std
>>> >
>>> > And another example:
>>> > If Arcane Jill puts a bigint
>>> >
>>> > etc/bigint/bigint.d        //module bigint.bigint;
>>> >
>>> > //it is afriend to all other modules in bigint (like prime.d) but
>>> > //not to any in etc
>>> >
>>> > etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd //is a friend to all modules in bigint.
>>> >
>>> > but you could also if you want do something like: etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd //now it is a friend only to all modules in bigint_files dir
>>> >
>>> > I know this this is probbably VERY stupid, and now i'm
>>> > waiting for someone to tell me why :) :)
>>>
>>> Well, I'm not sure but I think the module def at the top of the file is actually more important to the compiler than where the file is, so changing it from "module std.stream" to "module stream" means "import std.stream" will no longer work. I could be wrong.
>>
>> Did you really think i didn't try it before posting? :)
>> It DOES work.
> 
> Then what have I done wrong...
> 
> [d:\d\src\a\main.d]
> import bbb.abc;
> import ccc.def;
> 
> void main() {
> 	foo(5);
> 	bar(7);
> }
> 
> [d:\d\src\a\bbb\abc.d]
> module bbb.abc;
> 
> int foo(int a) {
> 	return a;
> }
> 
> [d:d\src\a\ccc\def.d]
> //module ccc.def;
> module def;
> 
> int bar(int a) {
> 	return a;
> }
> 
> D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt main.d(2): module def is in multiple packages def
> 
> ?
> 
>> Change in std/stream.d
>> module std.stream;
>> to module stream;
>>
>> And import it the usual way:
>> import std.stream;
>>
>> and everything works as usual, why not give the other definition  a new meaning :)
> 
> My gut feeling is that it's a bit weird. But like I said before modules and imports still seem a bit weird to me, how the file doesn't have to be in the 'right' directory...
> 
>>> My experience with modules seems to indicate to me that it doesn't
>>> matter
>>> where the file is actually stored so long as the module defs are correct
>>> in the file and then in the import line.
>>>
>>> This seemed weird at first.. and still seems weird to me.
>>
>> To me too, but i'm slowlly getting used to it!
>>
>>> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9vkin$2n9q$1@digitaldaemon.com...
>>> >> I definitely endorse the call for package level access, but the
>> question
>>> > "what
>>> >> is a package?" needs clarification before that can happen. Now, I
>>> know
>>> > that
>>> >> "package" is defined as "directory" in the docs, but when we ask for package-level access, I don't think we are exactly asking for
>>> > directory-level
>>> >> access. I certainly am not. Let me show you what I mean.
>>> >>
>>> >> My directory structure is currently as follows:
>>> >>
>>> >> etc\random.d
>>> >> etc\random_files\*.d
>>> >> etc\random_files\entropy\*.d
>>> >> etc\random_files\prbg\*d
>>> >>
>>> >> (As I've mentioned before I would prefer that I was allowed to have:
>>> >>
>>> >> etc\random.d
>>> >> etc\random\*.d
>>> >> etc\random\entropy\*.d
>>> >> etc\random\prbg\*d
>>> >>
>>> >> but the compiler annoyingly rejects that. Sorry dude - can't have a
>>> > directory
>>> >> with the same name and in the same directory as a .d file, no way. I hope
>>> > this
>>> >> is fixed, one day, but it's only an annoyance, not a show-stopper,
>>> so I
>>> > guess I
>>> >> can live with it for now).
>>> >>
>>> >> Anyway, the point is that, as I far as I am concerned, this entire
>>> > heirarchy is
>>> >> all part of the same package. For example,
>>> > "etc.random_files.entropy.noise" and
>>> >> "etc.random_files.prbg.forward_secure" are *friends*, and need access
>> to
>>> > each
>>> >> other's "package level" functions.
>>> >>
>>> >> And so I have a suggestion as to how this might work.
>>> >>
>>> >> SUGGESTION 1:
>>> >>
>>> >> The suggestion is that we define which package a module is in, right
>>> at
>>> > the
>>> >> start of the file. Like this:
>>> >>
>>> >> -----------------------------------------------
>>> >> >       module etc.random_files.entropy.noise;
>>> >> >       package etc.random_files;
>>> >> >       import whatever;
>>> >>
>>> >> -----------------------------------------------
>>> >> >       module etc.random_files.entropy.noise;
>>> >> >       package etc.random_files;
>>> >> >       import whatever;
>>> >>
>>> >> It would be a compile error if the package name were not an ancestor
>>> of
>>> > the
>>> >> module name.
>>> >>
>>> >> Now, with this system in force, I could then declare:
>>> >>
>>> >> >       package class MyClass
>>> >> >       {
>>> >> >       }
>>> >>
>>> >> and have that class visible everywhere within my directory tree, but
>>> > visible
>>> >> nowhere else.
>>> >>
>>> >> This suggestion mandates that a module can be in precisely one
>>> package
>>> >> and
>>> > no
>>> >> other, which may not be suitable for all situations, so I also have a
>>> > second
>>> >> suggestion (mutually contradictory with the first) which may be
>>> better
>>> >> for
>>> > some
>>> >> people.
>>> >>
>>> >> SUGGESTION 2:
>>> >>
>>> >> Instead of putting a package directive at the top of the file, we specify
>>> > it
>>> >> instead in the declaration, like this:
>>> >>
>>> >> >       package(etc.random_files) class MyClass
>>> >> >       {
>>> >> >       }
>>> >>
>>> >> Bingo! I've just declared that MyClass is visible anywhere in the
>>> > directory
>>> >> structure at or below etc.random_files, and nowhere else.
>>> >>
>>> >> Personally, I think that suggestion 2 is better than suggestion 1,
>>> > although
>>> >> suggestion 2 makes for cleaner source code.
>>> >>
>>> >> Arcane Jill
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>>
>>
>>
>>

The error happens because you coded 'module def;' instead of 'module ccc.def;' in 'd:d\src\a\ccc\def.d'.
-- 
Derek
Melbourne, Australia
8/Jun/04 10:24:58 AM

On Tue, 8 Jun 2004 10:26:46 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Mon, 07 Jun 2004 23:58:39 +1200, Regan Heath wrote:
>
>> On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji@public.srce.hr>
>> wrote:
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opr8702tr25a2sq9@digitalmars.com...
>>>> On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji
>>>> <ivan.senji@public.srce.hr>
>>>> wrote:
>>>> > Thinking about all this i came to a conclusion that things aren't
>>>> > that simple, but then i thought why not?
>>>> >
>>>> > The need for package level access is something most poeple agree
>>>> > on, and having all files in a package be friends is a good start, 
>>>> but
>>>> > here i propose a way to restrict this access in a way that each
>>>> > module decides who it want's to be friend with :)
>>>> >
>>>> > I will start with the example: By definition all modules in the 
>>>> "std"
>>>> > would be friends.
>>>> > for example
>>>> > std/stream.d:    module std.stream; //is a friend to everyone in std
>>>> > std/stream.d;    module stream; //it is still std.stream but it 
>>>> isn't
>>>> a
>>>> > //friend to anyone else in std
>>>> >
>>>> > And another example:
>>>> > If Arcane Jill puts a bigint
>>>> >
>>>> > etc/bigint/bigint.d        //module bigint.bigint;
>>>> >
>>>> > //it is afriend to all other modules in bigint (like prime.d) but
>>>> > //not to any in etc
>>>> >
>>>> > etc/bigint/bigint_files/gcd.d    //module bigint.bigint_files.gcd
>>>> > //is a friend to all modules in bigint.
>>>> >
>>>> > but you could also if you want do something like:
>>>> > etc/bigint/bigint_files/gcd.d    //module bigint_files.gcd
>>>> > //now it is a friend only to all modules in bigint_files dir
>>>> >
>>>> > I know this this is probbably VERY stupid, and now i'm
>>>> > waiting for someone to tell me why :) :)
>>>>
>>>> Well, I'm not sure but I think the module def at the top of the file is
>>>> actually more important to the compiler than where the file is, so
>>>> changing it from "module std.stream" to "module stream" means "import
>>>> std.stream" will no longer work. I could be wrong.
>>>
>>> Did you really think i didn't try it before posting? :)
>>> It DOES work.
>>
>> Then what have I done wrong...
>>
>> [d:\d\src\a\main.d]
>> import bbb.abc;
>> import ccc.def;
>>
>> void main() {
>> 	foo(5);
>> 	bar(7);
>> }
>>
>> [d:\d\src\a\bbb\abc.d]
>> module bbb.abc;
>>
>> int foo(int a) {
>> 	return a;
>> }
>>
>> [d:d\src\a\ccc\def.d]
>> //module ccc.def;
>> module def;
>>
>> int bar(int a) {
>> 	return a;
>> }
>>
>> D:\D\src\a>dmd -c ccc\def.d main.d bbb\abc.d -debug -g -gt
>> main.d(2): module def is in multiple packages def
>>
>> ?
>>
>>> Change in std/stream.d
>>> module std.stream;
>>> to module stream;
>>>
>>> And import it the usual way:
>>> import std.stream;
>>>
>>> and everything works as usual, why not give the other
>>> definition  a new meaning :)
>>
>> My gut feeling is that it's a bit weird. But like I said before modules
>> and imports still seem a bit weird to me, how the file doesn't have to be
>> in the 'right' directory...
>>
>>>> My experience with modules seems to indicate to me that it doesn't
>>>> matter
>>>> where the file is actually stored so long as the module defs are correct
>>>> in the file and then in the import line.
>>>>
>>>> This seemed weird at first.. and still seems weird to me.
>>>
>>> To me too, but i'm slowlly getting used to it!
>>>
>>>> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
>>>> > news:c9vkin$2n9q$1@digitaldaemon.com...
>>>> >> I definitely endorse the call for package level access, but the
>>> question
>>>> > "what
>>>> >> is a package?" needs clarification before that can happen. Now, I
>>>> know
>>>> > that
>>>> >> "package" is defined as "directory" in the docs, but when we ask 
>>>> for
>>>> >> package-level access, I don't think we are exactly asking for
>>>> > directory-level
>>>> >> access. I certainly am not. Let me show you what I mean.
>>>> >>
>>>> >> My directory structure is currently as follows:
>>>> >>
>>>> >> etc\random.d
>>>> >> etc\random_files\*.d
>>>> >> etc\random_files\entropy\*.d
>>>> >> etc\random_files\prbg\*d
>>>> >>
>>>> >> (As I've mentioned before I would prefer that I was allowed to 
>>>> have:
>>>> >>
>>>> >> etc\random.d
>>>> >> etc\random\*.d
>>>> >> etc\random\entropy\*.d
>>>> >> etc\random\prbg\*d
>>>> >>
>>>> >> but the compiler annoyingly rejects that. Sorry dude - can't have a
>>>> > directory
>>>> >> with the same name and in the same directory as a .d file, no way. 
>>>> I
>>>> >> hope
>>>> > this
>>>> >> is fixed, one day, but it's only an annoyance, not a show-stopper,
>>>> so I
>>>> > guess I
>>>> >> can live with it for now).
>>>> >>
>>>> >> Anyway, the point is that, as I far as I am concerned, this entire
>>>> > heirarchy is
>>>> >> all part of the same package. For example,
>>>> > "etc.random_files.entropy.noise" and
>>>> >> "etc.random_files.prbg.forward_secure" are *friends*, and need 
>>>> access
>>> to
>>>> > each
>>>> >> other's "package level" functions.
>>>> >>
>>>> >> And so I have a suggestion as to how this might work.
>>>> >>
>>>> >> SUGGESTION 1:
>>>> >>
>>>> >> The suggestion is that we define which package a module is in, 
>>>> right
>>>> at
>>>> > the
>>>> >> start of the file. Like this:
>>>> >>
>>>> >> -----------------------------------------------
>>>> >> >       module etc.random_files.entropy.noise;
>>>> >> >       package etc.random_files;
>>>> >> >       import whatever;
>>>> >>
>>>> >> -----------------------------------------------
>>>> >> >       module etc.random_files.entropy.noise;
>>>> >> >       package etc.random_files;
>>>> >> >       import whatever;
>>>> >>
>>>> >> It would be a compile error if the package name were not an 
>>>> ancestor
>>>> of
>>>> > the
>>>> >> module name.
>>>> >>
>>>> >> Now, with this system in force, I could then declare:
>>>> >>
>>>> >> >       package class MyClass
>>>> >> >       {
>>>> >> >       }
>>>> >>
>>>> >> and have that class visible everywhere within my directory tree, 
>>>> but
>>>> > visible
>>>> >> nowhere else.
>>>> >>
>>>> >> This suggestion mandates that a module can be in precisely one
>>>> package
>>>> >> and
>>>> > no
>>>> >> other, which may not be suitable for all situations, so I also 
>>>> have a
>>>> > second
>>>> >> suggestion (mutually contradictory with the first) which may be
>>>> better
>>>> >> for
>>>> > some
>>>> >> people.
>>>> >>
>>>> >> SUGGESTION 2:
>>>> >>
>>>> >> Instead of putting a package directive at the top of the file, we
>>>> >> specify
>>>> > it
>>>> >> instead in the declaration, like this:
>>>> >>
>>>> >> >       package(etc.random_files) class MyClass
>>>> >> >       {
>>>> >> >       }
>>>> >>
>>>> >> Bingo! I've just declared that MyClass is visible anywhere in the
>>>> > directory
>>>> >> structure at or below etc.random_files, and nowhere else.
>>>> >>
>>>> >> Personally, I think that suggestion 2 is better than suggestion 1,
>>>> > although
>>>> >> suggestion 2 makes for cleaner source code.
>>>> >>
>>>> >> Arcane Jill
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>>>
>>>
>>>
>>>
>
> The error happens because you coded 'module def;' instead of 'module
> ccc.def;' in 'd:d\src\a\ccc\def.d'.

Thanks Derek, but, that was the whole point :)
Ivan suggested this change could be allowed and also effect package access levels.

You must admit the error "main.d(2): module def is in multiple packages def" does not really say what you just said either, it suggests to me that I have 2 instances of module def, which I do not.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/