forbid field name conflict in class hierarchy

[Manfred_Nowak]

Jonathan M Davis wrote:

> It becomes easy to end up in a situation 
> where you're not using the one that you think that you're using

Which means that the model one is thinking in, is inconsistent with the 
model used in fact.

The OP used a model in which a name becomes invisible by redefinition 
only. He redefined a name without purpose, thereby evoking an error 
according to his aim.

The OP could have used a model in which a name becomes invisible by 
default, i.e. by using another file. But this would require to override 
the default of only local visibility of a name to a file.

Now the OP requires a model in which a name becomes invisible only, if 
one explicitely requires the invisibility by `new', `override', "forget" 
and what not.

But there are several more models for visibility changes---for example 
`import' states an explicit change in visibilty, `final' declarations 
disallow any loss of visibility---and because all of this models do have 
some advantages one might be tempted to use them in parallel.

But if one enables this variety of models the next complaint will 
inevitable be, that someone made an error because the model in fact used 
for some specific name, was not the model he was thinking in.

Therefore: no escape possible.

-manfred