www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Functions with package protection

reply Jacob Carlborg <doobnet gmail.com> writes:
In the D documentation at http://www.digitalmars.com/d/1.0/function.html 
it says the following: "All non-static non-private non-template member 
functions are virtual", but this seems not to be the case. What I've 
heard and as the following example shows functions declared as package 
are non-virtual.

module main;

import tango.io.Stdout;

class A
{
	package void foo ()
	{
		Stdout("A").newline;
	}
}

class B : A
{
	package void foo ()
	{
		Stdout("B").newline;
	}
}

void main ()
{
	A a = new B;
	a.foo;
}

This will print "A", but according to the documentation package is 
virtual and therefore this should print "B" but doesn't. Either the 
documentation is wrong or the compiler.

Compiled with GDC on OSX, I think it will give the same result with dmd 
also.
Jun 20 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Jacob Carlborg schrieb:
 In the D documentation at http://www.digitalmars.com/d/1.0/function.html 
 it says the following: "All non-static non-private non-template member 
 functions are virtual", but this seems not to be the case. What I've 
 heard and as the following example shows functions declared as package 
 are non-virtual.
 
 module main;
 
 import tango.io.Stdout;
 
 class A
 {
     package void foo ()
     {
         Stdout("A").newline;
     }
 }
 
 class B : A
 {
     package void foo ()
     {
         Stdout("B").newline;
     }
 }
 
 void main ()
 {
     A a = new B;
     a.foo;
 }
 
 This will print "A", but according to the documentation package is 
 virtual and therefore this should print "B" but doesn't. Either the 
 documentation is wrong or the compiler.
 
 Compiled with GDC on OSX, I think it will give the same result with dmd 
 also.

Unfortunately on http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute it is said: "Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."
Jun 20 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Frank Benoit wrote:
 Jacob Carlborg schrieb:
 In the D documentation at 
 http://www.digitalmars.com/d/1.0/function.html it says the following: 
 "All non-static non-private non-template member functions are 
 virtual", but this seems not to be the case. What I've heard and as 
 the following example shows functions declared as package are 
 non-virtual.

 module main;

 import tango.io.Stdout;

 class A
 {
     package void foo ()
     {
         Stdout("A").newline;
     }
 }

 class B : A
 {
     package void foo ()
     {
         Stdout("B").newline;
     }
 }

 void main ()
 {
     A a = new B;
     a.foo;
 }

 This will print "A", but according to the documentation package is 
 virtual and therefore this should print "B" but doesn't. Either the 
 documentation is wrong or the compiler.

 Compiled with GDC on OSX, I think it will give the same result with 
 dmd also.

Unfortunately on http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute it is said: "Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."

Yeah, but the documentation is still wrong. It's very annoying when the documentation is inconsistence, incomplete or just wrong. I can see why users unfamiliar with D have problems.
Jun 21 2008
prev sibling parent reply Simon TRENY <simon.treny free.fr> writes:
Sorry to dig up this old post, but I still don't understand why 'package'
functions cannot be virtual? Is there a good reason for this? I can't see why
we can't use polymorphism on 'package' functions!

Is there way to make it virtual without making it public? (e.g. a 'virtual'
keyword?)

Thanks,
Simon TRENY


Jacob Carlborg Wrote:

 In the D documentation at http://www.digitalmars.com/d/1.0/function.html 
 it says the following: "All non-static non-private non-template member 
 functions are virtual", but this seems not to be the case. What I've 
 heard and as the following example shows functions declared as package 
 are non-virtual.
 
 module main;
 
 import tango.io.Stdout;
 
 class A
 {
 	package void foo ()
 	{
 		Stdout("A").newline;
 	}
 }
 
 class B : A
 {
 	package void foo ()
 	{
 		Stdout("B").newline;
 	}
 }
 
 void main ()
 {
 	A a = new B;
 	a.foo;
 }
 
 This will print "A", but according to the documentation package is 
 virtual and therefore this should print "B" but doesn't. Either the 
 documentation is wrong or the compiler.
 
 Compiled with GDC on OSX, I think it will give the same result with dmd 
 also.

Jun 02 2009
next sibling parent reply grauzone <none example.net> writes:
 Sorry to dig up this old post, but I still don't understand why 'package'
functions cannot be virtual? Is there a good reason for this? I can't see why
we can't use polymorphism on 'package' functions!
 
 Is there way to make it virtual without making it public? (e.g. a 'virtual'
keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.
Jun 03 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why 
 'package' functions cannot be virtual? Is there a good reason for 
 this? I can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a 
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual: class A { package void foo() { printf("A"); } } class B { package void foo() { printf("B"); } } void main() { A a = new B(); a.foo(); }
Jun 03 2009
next sibling parent grauzone <none example.net> writes:
Robert Fraser wrote:
 grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why 
 'package' functions cannot be virtual? Is there a good reason for 
 this? I can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a 
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual: class A { package void foo() { printf("A"); } } class B { package void foo() { printf("B"); } } void main() { A a = new B(); a.foo(); }

I'd say this code relied on a bug, and fixing bugs is always allowed. Actually, it is very likely that the behavior above wasn't even intended by the programmer.
Jun 03 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:
 grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why 
 'package' functions cannot be virtual? Is there a good reason for 
 this? I can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a 
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual:

That's a larger problem, I think: you can override methods silently. The override keyword should be required.
Jun 03 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Jun 3, 2009 at 10:02 PM, Christopher Wright <dhasenan gmail.com> wrote:
 Robert Fraser wrote:
 grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why
 'package' functions cannot be virtual? Is there a good reason for this? I
 can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual:

That's a larger problem, I think: you can override methods silently. The override keyword should be required.

It is in D2.
Jun 03 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Simon TRENY wrote:
 Sorry to dig up this old post, but I still don't understand why 'package'
functions cannot be virtual? Is there a good reason for this? I can't see why
we can't use polymorphism on 'package' functions!
 
 Is there way to make it virtual without making it public? (e.g. a 'virtual'
keyword?)
 
 Thanks,
 Simon TRENY

As far as I can tell, 'package' is a buggy implementation of a broken concept. It seems to be completely useless.
Jun 03 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 04 Jun 2009 07:36:35 +0400, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Wed, Jun 3, 2009 at 10:02 PM, Christopher Wright <dhasenan gmail.com>  
 wrote:
 Robert Fraser wrote:
 grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why
 'package' functions cannot be virtual? Is there a good reason for  
 this? I
 can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual:

That's a larger problem, I think: you can override methods silently. The override keyword should be required.

It is in D2.

Since when?
Jun 04 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Jun 4, 2009 at 7:01 AM, Denis Koroskin <2korden gmail.com> wrote:
 On Thu, 04 Jun 2009 07:36:35 +0400, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Wed, Jun 3, 2009 at 10:02 PM, Christopher Wright <dhasenan gmail.com>
 wrote:
 Robert Fraser wrote:
 grauzone wrote:
 Sorry to dig up this old post, but I still don't understand why
 'package' functions cannot be virtual? Is there a good reason for
 this? I
 can't see why we can't use polymorphism on 'package' functions!

 Is there way to make it virtual without making it public? (e.g. a
 'virtual' keyword?)

"package" needs to fixes: - package methods must be allowed to be virtual - package methods must be allowed to be accessed from sub packages (module a.b.x should be able to access package identifiers declared in module a.y) I don't understand why these fixes applied, especially because they are completely backward compatible.

"package methods must be allowed to be virtual" isn't backwards-compatible. This code will work differently if package methods were made virtual:

That's a larger problem, I think: you can override methods silently. The override keyword should be required.

It is in D2.

Since when?

Since 2.004. I guess it's a warning and not an error, but I always compile with warnings anyway. In any case, it's almost *always* an error.
Jun 04 2009