package methods are final? huh?

Lodovico Giaretta via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 2 05:54:08 PDT 2016


On Sunday, 2 October 2016 at 12:21:19 UTC, Manu wrote:
> Why would something outside the package be able to see the 
> package
> function to override it?
> Surely the override would report an inaccessibility error 
> (referring
> to the base virtual)?

1) Usually a virtual function is also allowed to be abstract. 
Subclasses defined outside the package will not be able to 
implement that virtual function and will either fail compilation 
or crash at runtime.

2) Virtual functions are part of the public interface, as they 
partecipate in the vtable layout. So, allowing package virtuals, 
non-public functions would become part of the public interface.

3) A virtual method performs operations specific for each 
subclass (otherwise, there's no reason for having it virtual); 
what if a subclass defined outside of the package requires a 
different override?

I'm not saying that package functions should not be virtual at 
all. I'm saying that this thing must be carefully thought, as it 
doesn't really play well with cross-package inheritance.

By the way, the same discussion could be made for having private 
methods be virtual, as private applies to the module level, and a 
module may contain an entire hierarchy of classes.


More information about the Digitalmars-d mailing list