package methods are final? huh?

[Manu via Digitalmars-d]

On 2 October 2016 at 21:51, Lodovico Giaretta via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 2 October 2016 at 11:37:34 UTC, Manu wrote:
>>
>> [...]
>>
>> Why? I have a UI system with modules for each node type. UI internal stuff
>> is naturally 'package'. Virtuals are perfectly reasonable within a package.
>
>
> One reason I can think of: what happens if someone outside the package
> extends one of your classes?
>
> ===================================
>
> module packA.something;
>
> class Base
> {
>     abstract void foo();
> }
>
> module packB.something;
>
> class Derived1: Base
> {
>     override void foo() {}     // Oops... should not know about this method,
>                                //         but without it the class is
> abstract.
> }
> ===================================
>
> The fact is, package virtual is fine as long as the class cannot be extended
> outside the package, or can be extended outside the package but no subclass
> defined in this way may need a different definition of the method. Such a
> constraint is difficult to enforce in the language.

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)?