• Arcane Jill (46/58) Jun 06 2004 I definitely endorse the call for package level access, but the question...
• Arcane Jill (5/12) Jun 06 2004 Actually, they're not mutually contradictory after all. I've just realis...
• Ivan Senji (39/97) Jun 06 2004 Although i agree that package level acces is needed, i think a
• DemmeGod (18/145) Jun 06 2004 I don't like this idea. This basically says that friends can either hav...
• Ivan Senji (16/161) Jun 06 2004 this is how it works in C++ (if i understand it correctly)
• DemmeGod (4/16) Jun 06 2004 I don't like the way C++ does it, then. However, I do like the way java
• Arcane Jill (24/28) Jun 06 2004 Please could you tell me how Java DEFINES a package. It's been a while s...
• DemmeGod (27/65) Jun 06 2004 To tell you the truth, I don't know whether or not package level access ...
• Sam McCall (14/26) Jun 06 2004 The actual language spec says packages are just names, there is no
• Charlie (7/128) Jun 06 2004 Only problem I see with this is now all modules in
• Ivan Senji (21/156) Jun 06 2004 Yes the sugestion has it's problems. But i am sure Walter
• Ivan Senji (20/141) Jun 06 2004 I just though of another keyword that might be used in this context.
• Ben Hinkle (11/20) Jun 06 2004 One drawback of that particular proposal is that it probably would end u...
• Ivan Senji (12/32) Jun 06 2004 ones.
• Charlie (11/71) Jun 06 2004 Im an avid supporter of writing as little code as possible to get the jo...
• J C Calvarese (19/31) Jun 06 2004 This might not change any time soon.
• Arcane Jill (26/39) Jun 06 2004 I can actually see the problem. But it don't see why it can't be worked ...
• J C Calvarese (31/97) Jun 06 2004 Thanks for explaining. That could be the problem.
• Hauke Duden (10/96) Jun 06 2004 Personally I don't like this idea much. It seems way too complicated and...
• Martin M. Pedersen (28/86) Jun 06 2004 Another approach would be to change the definition of a compilation unit
• Ivan Senji (44/102) Jun 07 2004 Thinking about all this i came to a conclusion that things aren't
• Regan Heath (12/142) Jun 07 2004 Well, I'm not sure but I think the module def at the top of the file is
• Ivan Senji (14/166) Jun 07 2004 Did you really think i didn't try it before posting? :)
• Regan Heath (29/209) Jun 07 2004 Then what have I done wrong...
• Ivan Senji (7/32) Jun 07 2004 Yes, you are right! I tried only with std.stream, and not with
• =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= (5/19) Jun 07 2004 --
• Ivan Senji (4/23) Jun 07 2004 I tried private import but it doesn't change anything, still
• Derek Parnell (7/235) Jun 07 2004 The error happens because you coded 'module def;' instead of 'module
• Regan Heath (10/257) Jun 07 2004 Thanks Derek, but, that was the whole point :)
• J C Calvarese (9/35) Jun 07 2004 I think this message is confusing and incorrect to boot.
• Derek Parnell (8/19) Jun 07 2004 Oh..yeah..right...sorry about that. (Note to self: Must read slower.)
• Ivan Senji (7/19) Jun 08 2004 "Regan Heath" wrote in message
• =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= (12/102) Jun 07 2004 Actually, C# uses another keyword "internal" which works like "public"

Arcane Jill <Arcane_member pathlink.com> writes:

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

Arcane Jill <Arcane_member pathlink.com> writes:

In article <c9vkin$2n9q$1 digitaldaemon.com>, Arcane Jill says...

SUGGESTION 1:
       package etc.random_files;
       package class MyClass
       {

SUGGESTION 2:
       package(etc.random_files) class MyClass
       {


Actually, they're not mutually contradictory after all. I've just realised we
could actually allow both at once. We could even make the package directive at
the top of the file optional (defaulting to the current directory).

Arcane Jill

"Ivan Senji" <ivan.senji public.srce.hr> writes:

Although i agree that package level acces is needed, i think a
proposal Ben Hinkle made makes more sence because there is
no need for a new keyword:
pasted from his post:

file pkg/foo.d:
private module pkg.foo;
private int a;  // only visible in foo.d
int a2;         // visible in foo.d and bar.d but not outside pkg

file pkg/bar.d:
module pkg.bar;
private int b;  // visible in bar.d and foo.d but not outside pkg
int b2;         // visible anywhere

This way all files in a package would be friends by default (as are class
member functions in D) and if you wanted to make it not-friend
you would just declare it private.
Maybe we could also include protected to mean that that file(module)
can't be imported from outside of the package. Or maybe
private and protected should be the other way around, but anyway
Ben's idea looks like a really promissing one :)

"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

DemmeGod <me demmegod.com> writes:

I don't like this idea.  This basically says that friends can either have
no access or full access to my privates, but not limited access.  It's not
always appropriate for friends to have access to all privates, but they do
need access to some of them- making them not privates, but
package-privates (like secrets among friends.)  This is appropriate in
many cases.  A new keyword is needed to do this without making the syntax
very confusing.

Although AJ's idea of package(abc.def) isn't a bad idea, I don't think
it's necessary if the bug concerning identical module and package names is
fixed. (And it *is* a bug since it's not specs.) If this bug is fixed, all
that is needed is a package access level keyword... I'm also not sure why
declaring the package at the beginning of the module is necessary. The
definition of packages is quite clear: "The packages correspond to
directory names in the source file path." Package level access allows
access within the immediate package (and perhaps in sub-packages)

I don't see any need to complicate it.

John

On Sun, 06 Jun 2004 20:10:38 +0200, Ivan Senji wrote:

 Although i agree that package level acces is needed, i think a proposal
 Ben Hinkle made makes more sence because there is no need for a new
 keyword:
 pasted from his post:
 
 file pkg/foo.d:
 private module pkg.foo;
 private int a;  // only visible in foo.d int a2;         // visible in
 foo.d and bar.d but not outside pkg
 
 file pkg/bar.d:
 module pkg.bar;
 private int b;  // visible in bar.d and foo.d but not outside pkg int b2; 
        // visible anywhere
 
 This way all files in a package would be friends by default (as are class
 member functions in D) and if you wanted to make it not-friend you would
 just declare it private.
 Maybe we could also include protected to mean that that file(module) can't
 be imported from outside of the package. Or maybe private and protected
 should be the other way around, but anyway Ben's idea looks like a really
 promissing one :)
 
 "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

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.06.06.18.40.21.36370 demmegod.com...
 I don't like this idea.  This basically says that friends can either have
 no access or full access to my privates, but not limited access.  It's not

this is how it works in C++ (if i understand it correctly)
class A
{}
class B{friend class A;}

now A is a friend to B and has unlimited acces to B's members.

 always appropriate for friends to have access to all privates, but they do
 need access to some of them- making them not privates, but
 package-privates (like secrets among friends.)  This is appropriate in
 many cases.  A new keyword is needed to do this without making the syntax
 very confusing.

 Although AJ's idea of package(abc.def) isn't a bad idea, I don't think
 it's necessary if the bug concerning identical module and package names is
 fixed. (And it *is* a bug since it's not specs.) If this bug is fixed, all
 that is needed is a package access level keyword... I'm also not sure why
 declaring the package at the beginning of the module is necessary. The
 definition of packages is quite clear: "The packages correspond to
 directory names in the source file path." Package level access allows
 access within the immediate package (and perhaps in sub-packages)

 I don't see any need to complicate it.

We are here to complicate :) and bigW is here to make it simple :)

 John

 On Sun, 06 Jun 2004 20:10:38 +0200, Ivan Senji wrote:

 Although i agree that package level acces is needed, i think a proposal
 Ben Hinkle made makes more sence because there is no need for a new
 keyword:
 pasted from his post:

 file pkg/foo.d:
 private module pkg.foo;
 private int a;  // only visible in foo.d int a2;         // visible in
 foo.d and bar.d but not outside pkg

 file pkg/bar.d:
 module pkg.bar;
 private int b;  // visible in bar.d and foo.d but not outside pkg int


b2;
        // visible anywhere

 This way all files in a package would be friends by default (as are


class
 member functions in D) and if you wanted to make it not-friend you would
 just declare it private.
 Maybe we could also include protected to mean that that file(module)


can't
 be imported from outside of the package. Or maybe private and protected
 should be the other way around, but anyway Ben's idea looks like a


really
 promissing one :)

 "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

DemmeGod <me demmegod.com> writes:

On Sun, 06 Jun 2004 21:12:34 +0200, Ivan Senji wrote:

 "DemmeGod" <me demmegod.com> wrote in message
 news:pan.2004.06.06.18.40.21.36370 demmegod.com...
 I don't like this idea.  This basically says that friends can either
 have no access or full access to my privates, but not limited access. 
 It's not

 
 this is how it works in C++ (if i understand it correctly) class A
 {}
 class B{friend class A;}
 
 now A is a friend to B and has unlimited acces to B's members.
 

I don't like the way C++ does it, then.  However, I do like the way java
does it's package-level access: it's got a package keyword that allows
package access to that member.  It's simple, and it works well.

Arcane Jill <Arcane_member pathlink.com> writes:

In article <pan.2004.06.06.20.13.01.636964 demmegod.com>, DemmeGod says...

I don't like the way C++ does it, then.  However, I do like the way java
does it's package-level access: it's got a package keyword that allows
package access to that member.  It's simple, and it works well.

Please could you tell me how Java DEFINES a package. It's been a while since I
wrote in Java and I've forgotten. If memory serves correct (and it may not)
there isn't necessarily a 1-1 corresponce between packages and directories.
Thanks.


Maybe other people organize things differently from me. I like a nice clean
heirarchy, with everything in the "right" place. The way I see it, a package
must be a tree, not a flat dir, and so packages (by this definition) would
contain other packages (as directories contain other directories). If you want
to make something in one file visible outside that file, you need a way to
specify where (how far up the tree) that visibility stops. If it's visible all
the way up to "." then its public!

To be honest, I don't care what keywords we use to express this. I'd be happy
with more or less any syntex that did the job.

It just strikes me that, in general, the package "a.b.c.d" should include the
package "a.b.c.d.e.f".

For instance, I might want "a.b.c.d.e1.f1.MyClass" to be visible in
"a.b.c.d.e2.f2", but not in "a.b.c.d2...", so the visiblity of MyClass needs to
"a.b.c.d" and everything therebelow. Ideally, I'd want a way of expressing that
somehow within the declaration of MyClass. My suggestion:

In file a.b.c.d.e.f:
       package(a.b.c.d) MyClass

expresses this very nicely. I'm not hung up on the specific syntax, just on
being able to do it. This would be a very nice language feature.

Arcane Jill

DemmeGod <me demmegod.com> writes:

To tell you the truth, I don't know whether or not package level access in
Java allows sub-packages access, as I've never had to use it.

Java, however, does look for the class files in directories == packages.
Ex if you're importing a.b.c, it'll look for c.class in the directory a/b.
However, it does not require that the source be organized the same way.  I
always do, however.

I think we agree that package level access should allow sub-package
access. Ex:

module my.a.b;
class c
{
 package int d;
}

----------
module my.a.b.f;
c C = new c;
C.d = 6; //Should work

---------
module my.e;
c C = new c;
C.d = 6; //Should _not_ compile

I don't see any reason for anything more complicated than just that
package keyword.  If anything in module e has to access anything in
package my.a, the hierarchy has probably been set up poorly.  Do we agree
on all of this?

John

On Sun, 06 Jun 2004 21:01:03 +0000, Arcane Jill wrote:

 In article <pan.2004.06.06.20.13.01.636964 demmegod.com>, DemmeGod says...
 
I don't like the way C++ does it, then.  However, I do like the way java
does it's package-level access: it's got a package keyword that allows
package access to that member.  It's simple, and it works well.

 
 Please could you tell me how Java DEFINES a package. It's been a while
 since I wrote in Java and I've forgotten. If memory serves correct (and it
 may not) there isn't necessarily a 1-1 corresponce between packages and
 directories. Thanks.
 
 
 Maybe other people organize things differently from me. I like a nice
 clean heirarchy, with everything in the "right" place. The way I see it, a
 package must be a tree, not a flat dir, and so packages (by this
 definition) would contain other packages (as directories contain other
 directories). If you want to make something in one file visible outside
 that file, you need a way to specify where (how far up the tree) that
 visibility stops. If it's visible all the way up to "." then its public!
 
 To be honest, I don't care what keywords we use to express this. I'd be
 happy with more or less any syntex that did the job.
 
 It just strikes me that, in general, the package "a.b.c.d" should include
 the package "a.b.c.d.e.f".
 
 For instance, I might want "a.b.c.d.e1.f1.MyClass" to be visible in
 "a.b.c.d.e2.f2", but not in "a.b.c.d2...", so the visiblity of MyClass
 needs to "a.b.c.d" and everything therebelow. Ideally, I'd want a way of
 expressing that somehow within the declaration of MyClass. My suggestion:
 
 In file a.b.c.d.e.f:
       package(a.b.c.d) MyClass

 
 expresses this very nicely. I'm not hung up on the specific syntax, just
 on being able to do it. This would be a very nice language feature.
 
 Arcane Jill

Sam McCall <tunah.d tunah.net> writes:

Arcane Jill wrote:

 In article <pan.2004.06.06.20.13.01.636964 demmegod.com>, DemmeGod says...
 
 
I don't like the way C++ does it, then.  However, I do like the way java
does it's package-level access: it's got a package keyword that allows
package access to that member.  It's simple, and it works well.

 
 
 Please could you tell me how Java DEFINES a package. It's been a while since I
 wrote in Java and I've forgotten. If memory serves correct (and it may not)
 there isn't necessarily a 1-1 corresponce between packages and directories.
 Thanks.

The actual language spec says packages are just names, there is no 
superpackages/subpackage relationship. I don't think this is optimal, 
but i'm not sure if a tree of nested namespaces are the best either 
(foo.bar.module and foo.baz.module can't access each other's package 
members?)
As far as the standard implementation goes (the spec doesn't even 
mandate storing the classes on a filesystem!), you have a classpath 
variable that's a list of directories and zip/jar archives, by default 
containing the CWD, rt.jar (runtime) and maybe a few others.
Classes in the default package (when you don't specify a package name) 
are looked for in the root of each item in the classpath, classes in 
foo.bar would be looked for in /foo/bar/ of each item, and so on.
Sam

Charlie <Charlie_member pathlink.com> writes:

Only problem I see with this is now all modules in 

etc

are freinds ?

I guess you dont have to say module etc.pkg.foo; , drop the etc - and just place
it in etc/ (dir) ?  That would be cool I would vote for it.

Charlie

In article <c9vmmq$2q4r$1 digitaldaemon.com>, Ivan Senji says...
Although i agree that package level acces is needed, i think a
proposal Ben Hinkle made makes more sence because there is
no need for a new keyword:
pasted from his post:

file pkg/foo.d:
private module pkg.foo;
private int a;  // only visible in foo.d
int a2;         // visible in foo.d and bar.d but not outside pkg

file pkg/bar.d:
module pkg.bar;
private int b;  // visible in bar.d and foo.d but not outside pkg
int b2;         // visible anywhere

This way all files in a package would be friends by default (as are class
member functions in D) and if you wanted to make it not-friend
you would just declare it private.
Maybe we could also include protected to mean that that file(module)
can't be imported from outside of the package. Or maybe
private and protected should be the other way around, but anyway
Ben's idea looks like a really promissing one :)

"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

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Charlie" <Charlie_member pathlink.com> wrote in message
news:c9vojk$2sni$1 digitaldaemon.com...
 Only problem I see with this is now all modules in

 etc

 are freinds ?

Yes the sugestion has it's problems. But i am sure Walter
will read all sugestions and implement something that will
be very easy to use and understand. I'm just pouring my thoughts
in here.

By the way, in Walters original suggestion all modules in a package
are friends, and that way all modules in etc would indead be friends.
But the true problem is how to restrict this acces.

The modules that don't have anything to do with each oder
could be rewritten to: final private module etc.pkg.foo;

But it still doesn't answer the problem how to grant
acces to some modules in a package and not to others?
Or maybe this isn't a problem?

 I guess you dont have to say module etc.pkg.foo; , drop the etc - and just

place
 it in etc/ (dir) ?  That would be cool I would vote for it.

 Charlie

 In article <c9vmmq$2q4r$1 digitaldaemon.com>, Ivan Senji says...
Although i agree that package level acces is needed, i think a
proposal Ben Hinkle made makes more sence because there is
no need for a new keyword:
pasted from his post:

file pkg/foo.d:
private module pkg.foo;
private int a;  // only visible in foo.d
int a2;         // visible in foo.d and bar.d but not outside pkg

file pkg/bar.d:
module pkg.bar;
private int b;  // visible in bar.d and foo.d but not outside pkg
int b2;         // visible anywhere

This way all files in a package would be friends by default (as are class
member functions in D) and if you wanted to make it not-friend
you would just declare it private.
Maybe we could also include protected to mean that that file(module)
can't be imported from outside of the package. Or maybe
private and protected should be the other way around, but anyway
Ben's idea looks like a really promissing one :)

"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

"Ivan Senji" <ivan.senji public.srce.hr> writes:

I just though of another keyword that might be used in this context.
It is final.
for example:
final module pkg.foo; //this is a module pkg.foo that CAN be imported
//from outside of the package

module pkg.bar; //this is a pkg.bar module that can't be imported
//from the outside of the package but is friend to other modules in a
package

private module pkg.foo2; //a pkg.foo2 module that isn't friend to
//other modules in a package.

and even:
final private module pkg.bar2; //a module that can be imported from outside
//of the package but isn't friend to any other module in a package

...


"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c9vmmq$2q4r$1 digitaldaemon.com...
 Although i agree that package level acces is needed, i think a
 proposal Ben Hinkle made makes more sence because there is
 no need for a new keyword:
 pasted from his post:

 file pkg/foo.d:
 private module pkg.foo;
 private int a;  // only visible in foo.d
 int a2;         // visible in foo.d and bar.d but not outside pkg

 file pkg/bar.d:
 module pkg.bar;
 private int b;  // visible in bar.d and foo.d but not outside pkg
 int b2;         // visible anywhere

 This way all files in a package would be friends by default (as are class
 member functions in D) and if you wanted to make it not-friend
 you would just declare it private.
 Maybe we could also include protected to mean that that file(module)
 can't be imported from outside of the package. Or maybe
 private and protected should be the other way around, but anyway
 Ben's idea looks like a really promissing one :)

 "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

Ben Hinkle <bhinkle4 juno.com> writes:

 file pkg/foo.d:
 private module pkg.foo;
 private int a;  // only visible in foo.d
 int a2;         // visible in foo.d and bar.d but not outside pkg
 
 file pkg/bar.d:
 module pkg.bar;
 private int b;  // visible in bar.d and foo.d but not outside pkg
 int b2;         // visible anywhere

One drawback of that particular proposal is that it probably would end up
forcing files to be created when they shouldn't be.
Why? Private functions are mostly used as helper functions for public ones.
So if I have a public function I can only have package-level helpers and if
I want a module-level helper it can only be a helper for a package-level
function. That seems like too strong a restriction. I can imagine wanting
module-level helpers (or even class-level but I'm not going there) for
public functions and with this proposal it wouldn't work.
Basically when you look at existing code there aren't all that many
candidates for "private modules" as proposed above. 

-Ben

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c9vtrv$2kr$1 digitaldaemon.com...
 file pkg/foo.d:
 private module pkg.foo;
 private int a;  // only visible in foo.d
 int a2;         // visible in foo.d and bar.d but not outside pkg

 file pkg/bar.d:
 module pkg.bar;
 private int b;  // visible in bar.d and foo.d but not outside pkg
 int b2;         // visible anywhere

 One drawback of that particular proposal is that it probably would end up
 forcing files to be created when they shouldn't be.
 Why? Private functions are mostly used as helper functions for public

ones.
 So if I have a public function I can only have package-level helpers and

if
 I want a module-level helper it can only be a helper for a package-level
 function. That seems like too strong a restriction. I can imagine wanting

Good point, maybe then in case of private module, public should still
mean visible outside of the package, and have protected to mean
"protected" that is visible in the package but not outside of it.

There are isues to solve, but i have a feeling that it could be done
similar to this.

 module-level helpers (or even class-level but I'm not going there) for
 public functions and with this proposal it wouldn't work.
 Basically when you look at existing code there aren't all that many
 candidates for "private modules" as proposed above.

I agree, then Walters plan for package-level friend access would
be what i could live with, but there were people who where against
unrestricted package level-access.

 -Ben

Charlie <Charlie_member pathlink.com> writes:

Im an avid supporter of writing as little code as possible to get the job done (
less time to develop, fewer bugs ) and this to me looks far too verbose.

I like the idea of 'package level privacy' , but i think 

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

needs to be fixed.  I am alone in thinking the bugs need to be fixed before we
start adding more features ?

Or is this a permenant restriction on module naming ?  If so , I still think bug
fixing needs all/majority of the attention.

I do like suggestion 1, if we could drop the package attribute ( package class
foo ... ) and just have it implied.

Charlie


In article <c9vkin$2n9q$1 digitaldaemon.com>, Arcane Jill says...
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

J C Calvarese <jcc7 cox.net> writes:

Charlie wrote:

 Im an avid supporter of writing as little code as possible to get the job done
(
 less time to develop, fewer bugs ) and this to me looks far too verbose.
 
 I like the idea of 'package level privacy' , but i think 
 
 
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

 
 
 needs to be fixed.  I am alone in thinking the bugs need to be fixed before we
 start adding more features ?

This might not change any time soon.

DemmeGod has already posted this as a bug:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/168

Walter insists this won't work:
"Having the same name for both a package and a module just isn't going 
to work - sorry."
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/276

My suspicion is something fundamental about the compiler or liker 
prohibits this (but it's just a guess).

Perhaps we can work around this limitation with a simple convention:

instead of: module etc.bigint;
use: module etc.bigint.main;

I think something like that could work pretty well. (But I understand 
that's not as elegant as using the same name for a module and a package.)

Just a suggestion...

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Arcane Jill <Arcane_member pathlink.com> writes:

In article <ca00li$6i9$1 digitaldaemon.com>, J C Calvarese says...
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


My suspicion is something fundamental about the compiler or linker 
prohibits this (but it's just a guess).

I can actually see the problem. But it don't see why it can't be worked around.

Here's the problem: Suppose you have a FILE called abc/def/ghi.d. Suppose you
also have a DIRECTORY called abc/def/ghi. Now suppose that within the directory
ghi you had a file called abc/def/ghi/jkl.d In this scenario:

       import abc.def.ghi.jkl;

will read the file jkl.d, because "abc.def.ghi.jkl" refers to the module.

On the other hand, suppose that within the file abc/def/ghi.d you declared:

       public int jkl;

Now, "abc.def.ghi.jkl" refers to a variable. Compiler freaks out.


But what I /don't/ understand is why the compiler can't just reject such
ambiguities as compile-errors. It seems to me that the compiler is rejecting it
before the event, JUST IN CASE there might be an ambiguity later on. I don't get
it.



Perhaps we can work around this limitation with a simple convention:

instead of: module etc.bigint;
use: module etc.bigint.main;

I think something like that could work pretty well. (But I understand 
that's not as elegant as using the same name for a module and a package.)

The trouble with conventions is that unless Walter puts them in the style guide
*AND* has Phobos obey them, there's little chance that the rest of the world
will go along with them.

I used the "convention" that submodules all went in "etc.bigint_files".
Similarly, in my new project, the main import will be "etc.random", with
supporting files somewhere underneath "etc.random_files". I wanted the "normal"
import to have a nice short name. But that solution is still not particularly
elegant.


Now, apparently, Walter has said:
 Having the same name for both a package and a module
 just isn't going to work - sorry.

Walter, I don't suppose you could tell us why? What have I missed? Maybe we
could brainstorm and help you find a way round the problem, whatever it is? And
even if we can't, it would be nice to understand why it can't be done.

Cheers,
Jill

J C Calvarese <jcc7 cox.net> writes:

Arcane Jill wrote:
 In article <ca00li$6i9$1 digitaldaemon.com>, J C Calvarese says...
 
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


My suspicion is something fundamental about the compiler or linker 
prohibits this (but it's just a guess).

 
 
 I can actually see the problem. But it don't see why it can't be worked around.
 
 Here's the problem: Suppose you have a FILE called abc/def/ghi.d. Suppose you
 also have a DIRECTORY called abc/def/ghi. Now suppose that within the directory
 ghi you had a file called abc/def/ghi/jkl.d In this scenario:
 
 
      import abc.def.ghi.jkl;

 
 
 will read the file jkl.d, because "abc.def.ghi.jkl" refers to the module.
 
 On the other hand, suppose that within the file abc/def/ghi.d you declared:
 
 
      public int jkl;

 
 
 Now, "abc.def.ghi.jkl" refers to a variable. Compiler freaks out.
 
 
 But what I /don't/ understand is why the compiler can't just reject such
 ambiguities as compile-errors. It seems to me that the compiler is rejecting it
 before the event, JUST IN CASE there might be an ambiguity later on. I don't
get
 it.

Thanks for explaining. That could be the problem.

That gave me an idea of another possible problem:

module a;
enum b { item1, item2 }


module a.b;
const int item1 = 99;
const int item2 = 100;


module c;
import a;
import a.b;
void main()
{
     printf("%d\t%d\n", item1, item2);

     /* which items would be printed */
}


But, as with your example, I would expect that the compiler could detect 
  the ambiguous situation and print an error message. (I still wonder if 
a more serious problem exists behind the scenes.)


Perhaps we can work around this limitation with a simple convention:

instead of: module etc.bigint;
use: module etc.bigint.main;

I think something like that could work pretty well. (But I understand 
that's not as elegant as using the same name for a module and a package.)

 
 
 The trouble with conventions is that unless Walter puts them in the style guide
 *AND* has Phobos obey them, there's little chance that the rest of the world
 will go along with them.

I've found that if enough people demand a change, Walter can be 
persuaded to address an issue. Especially if there's a consensus on what 
the precise problem is.


 I used the "convention" that submodules all went in "etc.bigint_files".
 Similarly, in my new project, the main import will be "etc.random", with
 supporting files somewhere underneath "etc.random_files". I wanted the "normal"
 import to have a nice short name. But that solution is still not particularly
 elegant.

Have you considered a shorter directory name? (I'll throw out some 
unsolicited suggestions.)

_bigint
bigint_
bigint_mod (module)
bigint_pkg (package)


 
 Now, apparently, Walter has said:
 
Having the same name for both a package and a module
just isn't going to work - sorry.

 
 
 Walter, I don't suppose you could tell us why? What have I missed? Maybe we
 could brainstorm and help you find a way round the problem, whatever it is? And
 even if we can't, it would be nice to understand why it can't be done.
 
 Cheers,
 Jill
 
 


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Hauke Duden <H.NS.Duden gmx.net> writes:

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.


Personally I don't like this idea much. It seems way too complicated and 
is basically just another (slightly more restrictive) way to write 
"friend someModule".

I'm also not convinced that packages on different levels in the same 
hierarchy should have a way to access to each other's private members. 
Do you have an example when something like this is needed?

I DO agree that it should be possible to have files and 
directories/subpackages with the same name, though.

Hauke

"Martin M. Pedersen" <martin moeller-pedersen.dk> writes:

Another approach would be to change the definition of a compilation unit
from a module to a package. The compiler becomes a package-compiler, and a
package is the sources it is invoked with. The benefit will be that the
compiler knows that it has the complete package, and nothing else. It will
then be better able to perform optimizations within the package; ie. remove
calls through vtables, perform dead code removal etc.

It can be argued that package membership should be reflected in the source
files. That can be done too.

"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

"Ivan Senji" <ivan.senji public.srce.hr> writes:

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

Regan Heath <regan netwin.co.nz> writes:

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/

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"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/

Regan Heath <regan netwin.co.nz> writes:

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/

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"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 :)

=?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:

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/

"Ivan Senji" <ivan.senji public.srce.hr> writes:

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/

Derek Parnell <derek psych.ward> writes:

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

Regan Heath <regan netwin.co.nz> writes:

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/

J C Calvarese <jcc7 cox.net> writes:

Regan Heath wrote:
 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...




...


 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.

I think this message is confusing and incorrect to boot.

I've posted "bug reports" on similar messages. I don't think they're 
Walter's top priority (and probably rightly so), but I think they're 
good candidates for improvement.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Derek Parnell <derek psych.ward> writes:

On Tue, 08 Jun 2004 14:06:23 +1200, Regan Heath wrote:


[snip]

 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 :)

Oh..yeah..right...sorry about that. (Note to self: Must read slower.)

 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.

Yep! Bad message.

-- 
Derek
Melbourne, Australia
8/Jun/04 1:23:36 PM

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr886sxym5a2sq9 digitalmars.com...
.......
 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.

But we have a package attribute now, so i hope all problems are solved.

 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.

Exactly message should say something else, not sure exactly what,
but this one does imply that the module def is in more packages,
which is not true(or if it is, it is hard to understand)


 Regan.

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

=?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:

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