digitalmars.D - Virtuality and access specifiers (was: Disable GC entirely)
- Andrej Mitrovic (29/32) Apr 10 2013 Btw, you can see why this is n...
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.
Apr 10 2013