www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Does the 'package' protection attribute not work?

reply Stijn Herreman <stijn.herreman telenet.be> writes:
module main;

import std.stdio;
import my_module;

int main()
{
	my_method();
	return 0;
}


module my_module;

import std.stdio;

package void my_method()
{
	 writeln("Hello D-World!");
}


Error: function my_module.my_method is not accessible from main
Aug 07 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
 module main;
 
 import std.stdio;
 import my_module;
 
 int main()
 {
 	my_method();
 	return 0;
 }
 
 
 module my_module;
 
 import std.stdio;
 
 package void my_method()
 {
 	 writeln("Hello D-World!");
 }
 
 
 Error: function my_module.my_method is not accessible from main

Hmmm. My guess would be that either it's a bug or that from D's perspective, neither of your modules are in a package. They have no package in front of their names; they're at the base level of the hierarchy. And that might mean that they don't have a package, so they don't share a package. But I don't know. Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. - Jonathan M Davis
Aug 07 2011
next sibling parent Stijn Herreman <stijn.herreman telenet.be> writes:
On 7/08/2011 23:18, Jonathan M Davis wrote:
 On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
 module main;

 import std.stdio;
 import my_module;

 int main()
 {
 	my_method();
 	return 0;
 }


 module my_module;

 import std.stdio;

 package void my_method()
 {
 	 writeln("Hello D-World!");
 }


 Error: function my_module.my_method is not accessible from main

Hmmm. My guess would be that either it's a bug or that from D's perspective, neither of your modules are in a package. They have no package in front of their names; they're at the base level of the hierarchy. And that might mean that they don't have a package, so they don't share a package. But I don't know. Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. - Jonathan M Davis

under the impression it does: the files are in a subdirectory. Explicitly stating the package and module name in the files make the 'package' attribute work. So either the attribute does not work when the package and module name aren't explicitly stated, or a directory does not equal a package. From "The D Programming Language": "we refer to [...] a directory containing D source files as a package."
Aug 07 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when you're
 not actually using a package hierarchy (you're just making it so that
 everything but stuff which actually uses a hierarchy can use the function - it
 would be a really weird distinction to make). So, it wouldn't entirely
 surprise me if this is completely by design. It might be a bug though.

Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package -- Robert http://octarineparrot.com/
Aug 07 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-08 00:29, Robert Clipsham wrote:
 On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when
 you're
 not actually using a package hierarchy (you're just making it so that
 everything but stuff which actually uses a hierarchy can use the
 function - it
 would be a really weird distinction to make). So, it wouldn't entirely
 surprise me if this is completely by design. It might be a bug though.

Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package

In addition to that a method declared as "package" won't be virtual. -- /Jacob Carlborg
Aug 07 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/8/11 1:56 AM, Jacob Carlborg wrote:
 On 2011-08-08 00:29, Robert Clipsham wrote:
 On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when
 you're
 not actually using a package hierarchy (you're just making it so that
 everything but stuff which actually uses a hierarchy can use the
 function - it
 would be a really weird distinction to make). So, it wouldn't entirely
 surprise me if this is completely by design. It might be a bug though.

Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package

In addition to that a method declared as "package" won't be virtual.

Ouch. Why is that? Seems like a bug. Andrei
Aug 08 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-08 15:55, Andrei Alexandrescu wrote:
 On 8/8/11 1:56 AM, Jacob Carlborg wrote:
 On 2011-08-08 00:29, Robert Clipsham wrote:
 On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when
 you're
 not actually using a package hierarchy (you're just making it so that
 everything but stuff which actually uses a hierarchy can use the
 function - it
 would be a really weird distinction to make). So, it wouldn't entirely
 surprise me if this is completely by design. It might be a bug though.

Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package

In addition to that a method declared as "package" won't be virtual.

Ouch. Why is that? Seems like a bug. Andrei

Note, this is nothing new, it's been like this for ages. I don't know if it's by design or if it's a bug. The specification says: "All non-static non-private non-template member functions are virtual.", which would indicate that methods declared as "package" are virtual as well, but that has never been the case. This is the only issue I can find about it, but I'm quite sure it existed long before that: http://d.puremagic.com/issues/show_bug.cgi?id=3258 http://www.d-programming-language.org/function.html -- /Jacob Carlborg
Aug 08 2011
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-08-08 13:55:32 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 8/8/11 1:56 AM, Jacob Carlborg wrote:
 On 2011-08-08 00:29, Robert Clipsham wrote:
 On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when
 you're
 not actually using a package hierarchy (you're just making it so that
 everything but stuff which actually uses a hierarchy can use the
 function - it
 would be a really weird distinction to make). So, it wouldn't entirely
 surprise me if this is completely by design. It might be a bug though.

Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package

In addition to that a method declared as "package" won't be virtual.

Ouch. Why is that? Seems like a bug.

Seems by design. See dmd/src/func.c : int FuncDeclaration::isVirtual() { #if 0 … #endif Dsymbol *p = toParent(); return isMember() && !(isStatic() || protection == PROTprivate || protection == PROTpackage) && p->isClassDeclaration() && !(p->isInterfaceDeclaration() && isFinal()); } At least now you know where to fix this. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 08 2011
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 08/08/2011 02:10, Jonathan M Davis wrote:
 Ah. Then package is horribly broken at the moment. Lovely. I guess that that
 just goes to show that it's not used heavily or there would be a lot more
 complaints about it.

Another possibility is it's not used because it doesn't work - that's my current situation, and I don't bother complaining about it as these problems have been known since long before D1.0 was released, let alone D2. -- Robert http://octarineparrot.com/
Aug 08 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-07 23:18, Jonathan M Davis wrote:
 On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
 module main;

 import std.stdio;
 import my_module;

 int main()
 {
 	my_method();
 	return 0;
 }


 module my_module;

 import std.stdio;

 package void my_method()
 {
 	 writeln("Hello D-World!");
 }


 Error: function my_module.my_method is not accessible from main

Hmmm. My guess would be that either it's a bug or that from D's perspective, neither of your modules are in a package. They have no package in front of their names; they're at the base level of the hierarchy. And that might mean that they don't have a package, so they don't share a package. But I don't know. Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. - Jonathan M Davis

Or because neither of the modules are in package they are perhaps in an implicit global package making "package" in this case behave as public. -- /Jacob Carlborg
Aug 07 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-08 09:11, Jonathan M Davis wrote:
 On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote:
 Or because neither of the modules are in package they are perhaps in an
 implicit global package making "package" in this case behave as public.

Except that I don't think that sub-packages have access to the package functions in their parent packages, and if that's true, then it's not the same as public. However, if they _do_ have access to their parent packages' package functions, then it _is_ the same as public. I don't think that they do though. But of course, I could be wrong about that. - Jonathan M Davis

No, sub-packages don't have access to the parent package. Hence the "in this case". I guess I wasn't very clear. -- /Jacob Carlborg
Aug 08 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 08 August 2011 00:19:56 Stijn Herreman wrote:
 On 7/08/2011 23:18, Jonathan M Davis wrote:
 On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
 module main;
 
 import std.stdio;
 import my_module;
 
 int main()
 {
 
 	my_method();
 	return 0;
 
 }
 
 
 module my_module;
 
 import std.stdio;
 
 package void my_method()
 {
 
 	 writeln("Hello D-World!");
 
 }
 
 
 Error: function my_module.my_method is not accessible from main

Hmmm. My guess would be that either it's a bug or that from D's perspective, neither of your modules are in a package. They have no package in front of their names; they're at the base level of the hierarchy. And that might mean that they don't have a package, so they don't share a package. But I don't know. Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. - Jonathan M Davis

The actual code does make use of a package hierarchy. At least, I'm under the impression it does: the files are in a subdirectory. Explicitly stating the package and module name in the files make the 'package' attribute work. So either the attribute does not work when the package and module name aren't explicitly stated, or a directory does not equal a package. From "The D Programming Language": "we refer to [...] a directory containing D source files as a package."

TDPL is correct with regards to how packages are _supposed_ to work. Whether they _actually_ work that way at the moment, I don't know. I've rarely had use for them, so I'm not sure that I've ever actually tried it. There's every possibility that package is currently broken. But what you've read in TDPL is definitely how packages are supposed to work. - Jonathan M Davis
Aug 07 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 07 August 2011 23:29:26 Robert Clipsham wrote:
 On 07/08/2011 22:18, Jonathan M Davis wrote:
 Personally, I don't see much point in using the package specifier when
 you're not actually using a package hierarchy (you're just making it so
 that everything but stuff which actually uses a hierarchy can use the
 function - it would be a really weird distinction to make). So, it
 wouldn't entirely surprise me if this is completely by design. It might
 be a bug though.

hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package).
 - Jonathan M Davis

[1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package

Ah. Then package is horribly broken at the moment. Lovely. I guess that that just goes to show that it's not used heavily or there would be a lot more complaints about it. - Jonathan M Davis
Aug 07 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote:
 On 2011-08-07 23:18, Jonathan M Davis wrote:
 On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
 module main;
 
 import std.stdio;
 import my_module;
 
 int main()
 {
 
 	my_method();
 	return 0;
 
 }
 
 
 module my_module;
 
 import std.stdio;
 
 package void my_method()
 {
 
 	 writeln("Hello D-World!");
 
 }
 
 
 Error: function my_module.my_method is not accessible from main

Hmmm. My guess would be that either it's a bug or that from D's perspective, neither of your modules are in a package. They have no package in front of their names; they're at the base level of the hierarchy. And that might mean that they don't have a package, so they don't share a package. But I don't know. Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. - Jonathan M Davis

Or because neither of the modules are in package they are perhaps in an implicit global package making "package" in this case behave as public.

Except that I don't think that sub-packages have access to the package functions in their parent packages, and if that's true, then it's not the same as public. However, if they _do_ have access to their parent packages' package functions, then it _is_ the same as public. I don't think that they do though. But of course, I could be wrong about that. - Jonathan M Davis
Aug 08 2011