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


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."
Aug 07 2011
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 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 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.


 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


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