On 4/10/13, Andrej Mitrovic <andrej.mitrovich@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.