www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Package Declaration

reply "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 05 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 05 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
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/
Jun 06 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 06 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 06 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 06 2012