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

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

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

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

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

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

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

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

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

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