## digitalmars.D - Two suggestions for package level access

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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
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
package-privates (like secrets among friends.)  This is appropriate in
many cases.  A new keyword is needed to do this without making the syntax
very confusing.

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

I don't see any need to complicate it.

John

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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
"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
package-privates (like secrets among friends.)  This is appropriate in
many cases.  A new keyword is needed to do this without making the syntax
very confusing.

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

I don't see any need to complicate it.

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

John

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

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

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

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

b2;
// visible anywhere

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

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

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

really
promissing one :)

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right at

the
start of the file. Like this:

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

etc.random_files;
import whatever;

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

etc.random_files;
import whatever;

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

the
module name.

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

package class MyClass
{
}
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

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

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

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

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass {
}
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill


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

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

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

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

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

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

Jun 06 2004
Only problem I see with this is now all modules in

etc

are freinds ?

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

Charlie

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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
"Ivan Senji" <ivan.senji public.srce.hr> writes:
"Charlie" <Charlie_member pathlink.com> wrote in message
news:c9vojk$2sni$1 digitaldaemon.com...
Only problem I see with this is now all modules in

etc

are freinds ?

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

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

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

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

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

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

Charlie

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right at

the
start of the file. Like this:

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

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

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

the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

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

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

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

for
some
people.

SUGGESTION 2:

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

specify
it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill


Jun 06 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
I just though of another keyword that might be used in this context.
It is final.
for example:
final module pkg.foo; //this is a module pkg.foo that CAN be imported
//from outside of the package

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

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

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

...

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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
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
"Ivan Senji" <ivan.senji public.srce.hr> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c9vtrv$2kr$1 digitaldaemon.com...
file pkg/foo.d:
private module pkg.foo;
private int a;  // only visible in foo.d
int a2;         // visible in foo.d and bar.d but not outside pkg

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

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

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

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

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

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

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

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

-Ben


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

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

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:

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

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:

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

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:

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
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
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
"Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
Another approach would be to change the definition of a compilation unit
from a module to a package. The compiler becomes a package-compiler, and a
package is the sources it is invoked with. The benefit will be that the
compiler knows that it has the complete package, and nothing else. It will
then be better able to perform optimizations within the package; ie. remove
calls through vtables, perform dead code removal etc.

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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
"Ivan Senji" <ivan.senji public.srce.hr> writes:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

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

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

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

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 07 2004
Regan Heath <regan netwin.co.nz> writes:
On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji <ivan.senji public.srce.hr>
wrote:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

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

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

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the question

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

"etc.random_files.entropy.noise" and

each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right at

the
start of the file. Like this:

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

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

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

the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

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

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

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

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill

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

Jun 07 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8702tr25a2sq9 digitalmars.com...
On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji <ivan.senji public.srce.hr>
wrote:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

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

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

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

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

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

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

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right at

the
start of the file. Like this:

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

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

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

the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

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

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

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

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill

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


Jun 07 2004
Regan Heath <regan netwin.co.nz> writes:
On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji public.srce.hr>
wrote:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8702tr25a2sq9 digitalmars.com...
On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji
<ivan.senji public.srce.hr>
wrote:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

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

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

a
//friend to anyone else in std

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

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

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

Then what have I done wrong...

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

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

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

int foo(int a) {
return a;
}

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

int bar(int a) {
return a;
}

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

?

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

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

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

know
that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

so I
guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right

at
the
start of the file. Like this:

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

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

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

of
the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

This suggestion mandates that a module can be in precisely one

package
and

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

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

better
for

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill

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

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

Jun 07 2004
"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
=?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
"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
Derek Parnell <derek psych.ward> writes:
On Mon, 07 Jun 2004 23:58:39 +1200, Regan Heath wrote:

On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji <ivan.senji public.srce.hr>
wrote:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8702tr25a2sq9 digitalmars.com...
On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji
<ivan.senji public.srce.hr>
wrote:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

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

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

a
//friend to anyone else in std

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

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

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

Then what have I done wrong...

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

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

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

int foo(int a) {
return a;
}

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

int bar(int a) {
return a;
}

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

?

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

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

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

know
that
"package" is defined as "directory" in the docs, but when we ask for
package-level access, I don't think we are exactly asking for

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to have:

etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

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

so I
guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in, right

at
the
start of the file. Like this:

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

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

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

of
the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree, but

visible
nowhere else.

This suggestion mandates that a module can be in precisely one

package
and

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

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

better
for

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill

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

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

Jun 07 2004
Regan Heath <regan netwin.co.nz> writes:
On Tue, 8 Jun 2004 10:26:46 +1000, Derek Parnell <derek psych.ward> wrote:
On Mon, 07 Jun 2004 23:58:39 +1200, Regan Heath wrote:

On Mon, 7 Jun 2004 13:18:29 +0200, Ivan Senji
<ivan.senji public.srce.hr>
wrote:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8702tr25a2sq9 digitalmars.com...
On Mon, 7 Jun 2004 09:30:30 +0200, Ivan Senji
<ivan.senji public.srce.hr>
wrote:
Thinking about all this i came to a conclusion that things aren't
that simple, but then i thought why not?

The need for package level access is something most poeple agree
on, and having all files in a package be friends is a good start,

but
here i propose a way to restrict this access in a way that each
module decides who it want's to be friend with :)

I will start with the example: By definition all modules in the

"std"
would be friends.
for example
std/stream.d:    module std.stream; //is a friend to everyone in std
std/stream.d;    module stream; //it is still std.stream but it

isn't
a
//friend to anyone else in std

And another example:
If Arcane Jill puts a bigint

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

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

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

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

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

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

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

Then what have I done wrong...

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

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

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

int foo(int a) {
return a;
}

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

int bar(int a) {
return a;
}

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

?

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

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

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

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

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

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

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

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9vkin$2n9q$1 digitaldaemon.com...
I definitely endorse the call for package level access, but the

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

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

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

directory-level
access. I certainly am not. Let me show you what I mean.

My directory structure is currently as follows:

etc\random.d
etc\random_files\*.d
etc\random_files\entropy\*.d
etc\random_files\prbg\*d

(As I've mentioned before I would prefer that I was allowed to

have:
etc\random.d
etc\random\*.d
etc\random\entropy\*.d
etc\random\prbg\*d

but the compiler annoyingly rejects that. Sorry dude - can't have a

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

I
hope

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

so I
guess I
can live with it for now).

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

heirarchy is
all part of the same package. For example,

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

access

to
each
other's "package level" functions.

And so I have a suggestion as to how this might work.

SUGGESTION 1:

The suggestion is that we define which package a module is in,

right
at
the
start of the file. Like this:

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

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

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

ancestor
of
the
module name.

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

package class MyClass
{
}

and have that class visible everywhere within my directory tree,

but
visible
nowhere else.

This suggestion mandates that a module can be in precisely one

package
and

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

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

better
for

some
people.

SUGGESTION 2:

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

it
instead in the declaration, like this:

package(etc.random_files) class MyClass
{
}

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

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

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

although
suggestion 2 makes for cleaner source code.

Arcane Jill

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

The error happens because you coded 'module def;' instead of 'module
ccc.def;' in 'd:d\src\a\ccc\def.d'.

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

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

Regan.

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

Jun 07 2004
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
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 :)

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.

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

Jun 07 2004
"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
=?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
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