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.

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."

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.

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.

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

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();
}

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.

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.

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.

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.