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 reply 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
parent reply 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
parent reply "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
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
prev 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