Currently i have all of my Files in the same Directory.
Now i will split them up in several specific Sub-Directories, e.g. Graphics, System and so one. But i have a problem: Some Files of one Sub-Directory call methods from Files which are in other Sub-Directories.
Up to now i have no problem, because if all of them are in the same Directory i can define the method under the "package" label and any other Module in the same Package can access the method.
What if I have Subpackages? E.G. Namespace.Graphics.Foo will access a method in Namespace.System.Bar. "package" doesn't work anymore, although they are in the same main Package. Ist that a Bug? And what should i do?
In C++ i can use the friend declaration and i thougth i D "package" are the equivalent.

Sorry for my english.

On Tuesday, June 05, 2012 11:08:03 Namespace wrote:
> Currently i have all of my Files in the same Directory.
> Now i will split them up in several specific Sub-Directories,
> e.g. Graphics, System and so one. But i have a problem: Some
> Files of one Sub-Directory call methods from Files which are in
> other Sub-Directories.
> Up to now i have no problem, because if all of them are in the
> same Directory i can define the method under the "package" label
> and any other Module in the same Package can access the method.
> What if I have Subpackages? E.G. Namespace.Graphics.Foo will
> access a method in Namespace.System.Bar. "package" doesn't work
> anymore, although they are in the same main Package. Ist that a
> Bug? And what should i do?
> In C++ i can use the friend declaration and i thougth i D
> "package" are the equivalent.
> 
> Sorry for my english.

package is only for modules in the same package, and a package is made up of all of the modules within a directory. Sub-directories are not part of the package. Sub-packages do not have access to package functions in their parent package, nor does a parent package have access to package functions in its sub-packages. Anything shared between them must be public. There is no way to give other packages (be they sub-packages or otherwise) access to a package's functions other than through public (or protected if you're dealing with inheritance).

As for friend, D's solution was to make private be private to a module rather than a class or struct. So, everything within a module is effectively a friend to everything else in that module. package comes from Java.

- Jonathan M Davis

On Tue, 05 Jun 2012 10:29:23 +0100, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, June 05, 2012 11:08:03 Namespace wrote:
>> Currently i have all of my Files in the same Directory.
>> Now i will split them up in several specific Sub-Directories,
>> e.g. Graphics, System and so one. But i have a problem: Some
>> Files of one Sub-Directory call methods from Files which are in
>> other Sub-Directories.
>> Up to now i have no problem, because if all of them are in the
>> same Directory i can define the method under the "package" label
>> and any other Module in the same Package can access the method.
>> What if I have Subpackages? E.G. Namespace.Graphics.Foo will
>> access a method in Namespace.System.Bar. "package" doesn't work
>> anymore, although they are in the same main Package. Ist that a
>> Bug? And what should i do?
>> In C++ i can use the friend declaration and i thougth i D
>> "package" are the equivalent.
>>
>> Sorry for my english.
>
> package is only for modules in the same package, and a package is made up of
> all of the modules within a directory. Sub-directories are not part of the
> package. Sub-packages do not have access to package functions in their parent
> package, nor does a parent package have access to package functions in its
> sub-packages. Anything shared between them must be public. There is no way to
> give other packages (be they sub-packages or otherwise) access to a package's
> functions other than through public (or protected if you're dealing with
> inheritance).
>
> As for friend, D's solution was to make private be private to a module rather
> than a class or struct. So, everything within a module is effectively a friend
> to everything else in that module. package comes from Java.

I think it would be nice, and allow for most common designs to allow package access from sub-packages to parent packages, but not the other way round.  So, sub-package "Namespace.Graphics.Foo" could access package methods defined in parent package Namespace.Graphics modules, but Namespace.Graphics could not access Namespace.Graphics.Foo, Namespace.Graphics.Bar, etc.

What do you reckon?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, June 06, 2012 10:33:58 Regan Heath wrote:
> I think it would be nice, and allow for most common designs to allow package access from sub-packages to parent packages, but not the other way round.  So, sub-package "Namespace.Graphics.Foo" could access package methods defined in parent package Namespace.Graphics modules, but Namespace.Graphics could not access Namespace.Graphics.Foo, Namespace.Graphics.Bar, etc.
> 
> What do you reckon?

I would think that in some cases you would want parent packages to have access to sub-packages' package stuff, and in some cases, you would want the reverse - or even both. But if you allow both, then that's the same as public, and even allowing it only one way is getting too close to public IMHO. And since people would sometimes want it one way and sometimes another, it would be a bit like the mess that typedef is - it frequently doesn't do quite what you want (hence why it's being removed from the language).

On the whole, it's just simpler for it to stay as it is, particularly since the language itself doesn't really have a concept of sub-packages. For instance, std is no different from std.etc.c or std.net as far as std.etc is concerned.

- Jonathan M Davis

And why haven't D any package System, e.g. like in Java were it is legal to access methods or classes which are in the same package?
The current module system is very nice, but it have limits.

On Wednesday, June 06, 2012 12:40:20 Namespace wrote:
> And why haven't D any package System, e.g. like in Java were it is legal to access methods or classes which are in the same package?

It _does_ have a package system. The package access level works within a package - i.e. within a folder. So for instance, everything in std.net which has package access can be accessed by any of the other modules in std.net but not by any other modules.

> The current module system is very nice, but it have limits.

Every module system does. There are pros and cons to any set of design decisions. D's module system may not be perfect, but it works very well overall.

- Jonathan M Davis