forbid field name conflict in class hierarchy

[Jonathan M Davis]

On Sunday 14 November 2010 11:29:55 spir wrote:
> On Sun, 14 Nov 2010 22:09:59 +0300
> Stanislav Blinov <stanislav.blinov at gmail.com> wrote:
> > This issue has been brought up several times before. I myself see no
> > harm in this shadowing, though making a compiler issue a warning
> > when shadowing *public* fields occurs would be a good thing.
> > Shadowing non-public fields, in my opinion, is harmless, and preventing
> > it would actually narrow down name choice with each subsequent
> > subclassing.
> 
> I don't understand in which case you need to reuse the same name in a
> subclass for a _different_ field -- whether the field is public or private
> does not seem really relevant to me. But maybe I overlook some common use
> case.

Private fields are effectively hidden from derived classes. Derived classes 
shouldn't care what they're named and shouldn't have to care. The only time that 
it becomes any kind of issue is if both the base class and derived class are in 
the same module, since then the derived class has access to the base class' 
private members and functions (even though it probably shouldn't actually use 
them) from being in the same module.

Having public fields shadow each other is problematic. Having private fields do so 
should be irrelevant.

- Jonathan M Davis