On Monday, April 02, 2012 20:02:20 deadalnix wrote: > Le 02/04/2012 19:10, Jonathan M Davis a écrit : > > On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote: > >> It's all nice and well, but I believe part of the reason of say private > >> protection is that user is never ever able to see(!) it. Thus it user > >> can't depend on private members being there, which is a good thing. > >> If I read it right, the technique you present allows user code to depend > >> on private functions being there. > >> I argue that we shouldn't even provide a _possibility_ for external > >> stuff to depend on private members. > >> Same argument in limited scope goes for protected. > > > > As it stands, private has _no_ effect on symbol visibility. All it affects > > is symbol accessibility. For instance, if you create a private alias in a > > module, it affects every module that imports your module, or if you > > create a function which causes an overload conflict, it creates an > > overload conflict regardless of whether it's private or not. C++ is the > > same way. Access modifiers are just that, _access_ modifieres. They > > _only_ affect accessibility, not visibility. > Reflection should reflect what the reflectee is. Private stuff are part > of the reflectee.
It may be that private stuff needs to be visible for some reflection stuff (particularly if you're dealing with lower level stuff) - I don't know. But at minimum, removing it from overload resolution would be a huge win. > > Now, there are a number of people very unhappy about this state of affairs > > and want private to hide symbols as well (personally, I think that the > > fact that it makes private aliases effectively useless is reason enough > > to seriously reconsider the current behavior), but I don't know if > > there's any real chance of convincing Walter or not. > > This would be a huge mistake. For instance, private method are sometime > meant to be overridden in subclasses, which is impossible if symbol is > inaccessible. > > NVI for instance would be impossible in such a situation. 1. NVI works perfectly well with protected functions. 2. private is currently never virtual in D anyway. If you want a function to be virtual, it must be public or protected. 3. Making private virtual would be a huge detriment to the language, because it would make all classes inefficient by default. You'd have to mark all non-NVI private functions functions final for them to be non-virtual and inlinable, so the default is then inefficient just to enable NVI with private functions. And since NVI works with protected, there's no real gain. http://d.puremagic.com/issues/show_bug.cgi?id=4542 - Jonathan M Davis