Module-level accessibility

[Steven Schveighoffer]

On Mon, 04 Oct 2010 15:14:09 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/4/10 13:27 CDT, Denis Koroskin wrote:


>> And the "package" also implying final is just ridiculous!

This I agree with.

>> I agree. Class A can access private methods of class B as long as both
>> defined in the same module. If it has access to private methods, why
>> can't it override them? Makes little sense, if you ask me, especially
>> given that user may prevent overriding methods using "final" keyword.
>
> This is a very good argument that in my mind settles the case.

I don't understand the objection to using protected?

class A
{
    final void pubfunc() { foo(); }
    protected void foo() {writeln("A");}
}

class B : A
{
    /*final*/ protected void foo() {writeln("B");}
}

Make B.foo final if you don't want more derived functions from it.  What  
is the issue with this solution?

Note that private functions don't need to be declared in an interface  
file, but they would have to be if they are in the vtable.

My concern is that most of the time a final function isn't meant to be  
overridden.  What you end up with is silent, useless virtualization.  We  
are catering to the (very) uncommon case.

I would not object to this being implemented if:

A) The compiler only allocated a vtable spot for the function if it was  
detected to be overridden in a derived class.  This is easily detected  
since the only classes that can override such a function would be in the  
same module.  This still means the private function must appear in the .di  
file, but only when they are virtual.

B) Override was a required term for functions that override others (I know  
this is planned, but let's get this in there first).

I still see no pain because of the current implementation, I'm able to get  
by just fine.

-Steve