www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Two suggestions for package level access

reply 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
Jun 06 2004
next sibling parent 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
Jun 06 2004
prev sibling next sibling parent reply "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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill

Jun 06 2004
next sibling parent reply 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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 module name.

 Now, with this system in force, I could then declare:

       package class MyClass
       {
       }
       }


 nowhere else.

 This suggestion mandates that a module can be in precisely one package
 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better
 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass {
       }
       }


 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill


Jun 06 2004
parent reply "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


        // visible anywhere

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


 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)


 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


 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



 "what
 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access



 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

 start of the file. Like this:

 -----------------------------------------------
       module etc.random_files.entropy.noise; package




       import whatever;

-----------------------------------------------
       module etc.random_files.entropy.noise; package




       import whatever;

It would be a compile error if the package name were not an ancestor of

 module name.

 Now, with this system in force, I could then declare:

       package class MyClass
       {
       }
       }


 nowhere else.

 This suggestion mandates that a module can be in precisely one package
 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better
 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass {
       }
       }


 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill



Jun 06 2004
parent reply 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.
Jun 06 2004
parent reply 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
Jun 06 2004
next sibling parent 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

Jun 06 2004
prev sibling parent 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.

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
Jun 06 2004
prev sibling next sibling parent reply 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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill


Jun 06 2004
parent "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

 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



"what
 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I



this
 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access



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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package



no
 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better



some
 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we



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

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill



Jun 06 2004
prev sibling next sibling parent "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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I


 this
 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package


 no
 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better


 some
 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we


 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

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill


Jun 06 2004
prev sibling parent reply 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
Jun 06 2004
parent "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

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

 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

Jun 06 2004
prev sibling next sibling parent reply 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

Jun 06 2004
parent reply 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: 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." 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/
Jun 06 2004
parent reply 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
Jun 06 2004
parent 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/
Jun 06 2004
prev sibling next sibling parent 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
Jun 06 2004
prev sibling next sibling parent "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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill

Jun 06 2004
prev sibling next sibling parent reply "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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill

Jun 07 2004
parent reply 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

 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I 
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access to

 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package 
 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better 
 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we 
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 07 2004
parent reply "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



 "what
 is a package?" needs clarification before that can happen. Now, I know

 "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

 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

 with the same name and in the same directory as a .d file, no way. I
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, so I

 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access



 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

 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

 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one package
 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be better
 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 suggestion 2 makes for cleaner source code.

 Arcane Jill


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

Jun 07 2004
parent reply 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 

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



 "what
 is a package?" needs clarification before that can happen. Now, I 


 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

 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

 with the same name and in the same directory as a .d file, no way. I
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, 


 guess I
 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access



 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 


 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


 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one 


 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be 


 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 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/
Jun 07 2004
next sibling parent reply "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 :)
Jun 07 2004
parent reply =?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/
Jun 07 2004
parent "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/

Jun 07 2004
prev sibling parent reply 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 

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



 "what
 is a package?" needs clarification before that can happen. Now, I 


 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

 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

 with the same name and in the same directory as a .d file, no way. I
 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper, 


 guess I
 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need access



 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 


 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


 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

 nowhere else.

 This suggestion mandates that a module can be in precisely one 


 and

 other, which may not be suitable for all situations, so I also have a

 suggestion (mutually contradictory with the first) which may be 


 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 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
Jun 07 2004
parent reply 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, 

 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 

 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 

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



 "what
 is a package?" needs clarification before that can happen. Now, I


 that
 "package" is defined as "directory" in the docs, but when we ask 


 package-level access, I don't think we are exactly asking for

 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 


 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

 with the same name and in the same directory as a .d file, no way. 


 hope

 is fixed, one day, but it's only an annoyance, not a show-stopper,


 guess I
 can live with it for now).

 Anyway, the point is that, as I far as I am concerned, this entire

 all part of the same package. For example,

 "etc.random_files.prbg.forward_secure" are *friends*, and need 



 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, 


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


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,


 visible
 nowhere else.

 This suggestion mandates that a module can be in precisely one


 and

 other, which may not be suitable for all situations, so I also 


 second
 suggestion (mutually contradictory with the first) which may be


 for

 people.

 SUGGESTION 2:

 Instead of putting a package directive at the top of the file, we
 specify

 instead in the declaration, like this:

       package(etc.random_files) class MyClass
       {
       }

Bingo! I've just declared that MyClass is visible anywhere in the

 structure at or below etc.random_files, and nowhere else.

 Personally, I think that suggestion 2 is better than suggestion 1,

 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/
Jun 07 2004
next sibling parent 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/
Jun 07 2004
prev sibling next sibling parent 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
Jun 07 2004
prev sibling parent "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/

Jun 08 2004
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Actually, C# uses another keyword "internal" which works like "public" 
inside the assembly and "private" for all other files.


Arcane Jill wrote:

 I definitely endorse the call for package level access, but the question "what
 is a package?" needs clarification before that can happen. Now, I know that
 "package" is defined as "directory" in the docs, but when we ask for
 package-level access, I don't think we are exactly asking for directory-level
 access. I certainly am not. Let me show you what I mean.
 
 My directory structure is currently as follows:
 
 etc\random.d
 etc\random_files\*.d
 etc\random_files\entropy\*.d
 etc\random_files\prbg\*d
 
 (As I've mentioned before I would prefer that I was allowed to have:
 
 etc\random.d
 etc\random\*.d
 etc\random\entropy\*.d
 etc\random\prbg\*d
 
 but the compiler annoyingly rejects that. Sorry dude - can't have a directory
 with the same name and in the same directory as a .d file, no way. I hope this
 is fixed, one day, but it's only an annoyance, not a show-stopper, so I guess I
 can live with it for now).
 
 Anyway, the point is that, as I far as I am concerned, this entire heirarchy is
 all part of the same package. For example, "etc.random_files.entropy.noise" and
 "etc.random_files.prbg.forward_secure" are *friends*, and need access to each
 other's "package level" functions.
 
 And so I have a suggestion as to how this might work.
 
 SUGGESTION 1:
 
 The suggestion is that we define which package a module is in, right at the
 start of the file. Like this:
 
 -----------------------------------------------
 
      module etc.random_files.entropy.noise;
      package etc.random_files;
      import whatever;

-----------------------------------------------
      module etc.random_files.entropy.noise;
      package etc.random_files;
      import whatever;

It would be a compile error if the package name were not an ancestor of the module name. Now, with this system in force, I could then declare:
      package class MyClass
      {
      }

and have that class visible everywhere within my directory tree, but visible nowhere else. This suggestion mandates that a module can be in precisely one package and no other, which may not be suitable for all situations, so I also have a second suggestion (mutually contradictory with the first) which may be better for some people. SUGGESTION 2: Instead of putting a package directive at the top of the file, we specify it instead in the declaration, like this:
      package(etc.random_files) class MyClass
      {
      }

Bingo! I've just declared that MyClass is visible anywhere in the directory structure at or below etc.random_files, and nowhere else. Personally, I think that suggestion 2 is better than suggestion 1, although suggestion 2 makes for cleaner source code. Arcane Jill

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