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.
