traits getProtection

[Jonathan M Davis]

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