traits getProtection

[deadalnix]

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.

> 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.