Virtuality and access specifiers (was: Disable GC entirely)

[Andrej Mitrovic]

On 4/10/13, Andrej Mitrovic <andrej.mitrovich at gmail.com> wrote:
> In fact, it might go hand-in-hand with changing how protection
> attributes affect virtuality (currently they do, I'd argue they
> shouldn't)

Btw, you can see why this is needed in libraries like DFL. It uses
protected overrides for internal API functionality which the user
should never invoke, but because protected is still accessible to the
user the designer decided to either prepend an underscore behind the
method names to make them "appear" like they're API-only methods or in
other cases it uses comments instead.

It's clearly a wanted feature, take a look at these snippets verbatim
copied from some of its internal methods:

/+ package +/ protected override LONG save(HKEY hkey, Dstring name); // package
/+ package +/ /+ protected +/ override int _rtype(); // package
protected override void onReflectedMessage(ref Message m) // package
void _destroying() // package

Just do a search for "// package", there's loads of these. Slightly
related to this (going off-topic now) are also some templates which
are in packages, which should only be accessible to the library and
not the user, but they are public since package access disallows
super/sub packages access to symbols. They also have a "// package"
comment.

Anyway I think using underscores or comments to mark a method as an
internal API method is as lousy as Go's idea about using variable name
casing to determine their access.

I've had the same problem while designing my own library
functionality. I had the choice to either use inheritance (meaning
methods must be public or protected, and use an underscore for
"documentation purposes"), or to tag all my class objects and then do
casting to their dynamic type in order to invoke some internal package
or private method.

Both solutions are ugly.