forbid field name conflict in class hierarchy

[spir]

On Sun, 14 Nov 2010 22:09:59 +0300
Stanislav Blinov <stanislav.blinov at gmail.com> wrote:

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

I don't understand in which case you need to reuse the same name in a subclass for a _different_ field -- whether the field is public or private does not seem really relevant to me. But maybe I overlook some common use case.

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

Here, I guess you're touching programming style. I personly am allergic to accessors for everything.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com