forbid field name conflict in class hierarchy

Daniel Gibson metalcaedes at gmail.com
Sun Nov 14 11:32:07 PST 2010


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.
>> Remain unintentional name crash: eg forgot to remove a field when 
>> established type hierarchy. Allowing same names lead to strange 
>> contradictions by the language -- see below. Without such a rigor 
>> imposed the compiler, we can easily fall into traps such as:
>>
>> class C {
>>     int i;
>>     this (int i) {
>>         this.i = i;
>>     }
>> }
>> class C1 : C {
>>     // forgot to remove i
>>     int i;
>>     int j;
>>     this (int i, int j) {
>>         super(i);    // think i is set?
>>         this.j = j;
>>     }
>> }
>> void main () {
>>     auto c1 = new C1(1,2);
>>     writeln(c1.i);  // 0
>> }
>>
>> Got me 3 times already. I don't understand how it is even possible 
>> that C.i is not the same as C1.i, but evidence is here... There is a 
>> contradiction: i is set && not set. (explaination welcome ;-)
>>
>> Denis
>> -- -- -- -- -- -- --
>> vit esse estrany ☣
>>
>> spir.wikidot.com
>>
> 
> 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.

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


More information about the Digitalmars-d mailing list