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