forbid field name conflict in class hierarchy

[Stanislav Blinov]

Daniel Gibson wrote:
> Stanislav Blinov schrieb:
>> spir wrote:
>>> Hello,
>>>
>>>
>>> I think the compiler should complain when sub-classes hold fields 
>>> with the same name as super-classes. After all, names (in addition to 
>>> types) are used to identify. Intentionally reusing the same name 
>>> would not only be bad design, but open the door to hidden bugs.
>>
>> 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.
>>
> 
> No, only shadowing private fields is harmless (because the sub-class 
> can't access them anyway), but shadowing protected fields is about as 
> bad as shadowing public fields.
> 

Well, yes. Even shadowing of private fields is as bad as long as a 
subclass is in the same module as base class. Come to think of it, 
maybe, it'd be better if the compiler warned about shadowing whenever 
shadowed name is directly visible, not just in case of public fields.

Though the problem fully manifests itself in client code, where only 
public members are exposed.

>> The other option that comes to mind is simply disallow public fields 
>> for classes. This may sound too strict, but I think that public fields 
>> is something that's not as usable for classes as for structs.
> 
> Disallowing public fields is too restrictive IMHO.

Maybe. I just always view public fields as encapsulation breakers. And 
silent invariant breakers. And maintenance cripplers :)