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.
