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