www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - generalizing hiding rules

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I was just playing with some nested classes:

class Base {
     int x;
}

class A {
     private int x, y;
     class B : Base {
         int z;
         this() {
             x = 42;
             y = 43;
             this.outer.x = 44;
             z = 45;
         }
     }
}

In the code above, if you just write "x" in A.B's constructor, Base.x is 
fetched. So Base.x hides this.outer.x.

Disallowing hiding vertically in nested scopes has been quite 
successful. Also, D's no-hijack stance is also shaping up to be a hit. I 
am therefore thinking - why not apply the no-hijack rule throughout the 
language?

If one symbol leads to working code through two different lookups, an 
ambiguity error would be issued. The only exception would be if one 
symbol is scoped and the other is at module scope (for the reasons I 
discussed in another post).

I wonder to what extent this would break modular code, or foster more 
intelligible code. With this rule in tow, A.B.this() would have to use 
Base.x and this.outer.x to access the two x's.

What do you think?


Andrei
Oct 02 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Disallowing hiding vertically in nested scopes has been quite 
 successful. Also, D's no-hijack stance is also shaping up to be a hit. I 
 am therefore thinking - why not apply the no-hijack rule throughout the 
 language?

I agree that making D tidier in such regards is positive, helps avoid errors. "Explicit is better than implicit" says Python Zen (even if in such attribute scoping regards Python has some design holes). Bye, bearophile
Oct 02 2009
prev sibling parent Marianne Gagnon <auria.mg gmail.com> writes:
Andrei Alexandrescu Wrote:
 
 Disallowing hiding vertically in nested scopes has been quite 
 successful. Also, D's no-hijack stance is also shaping up to be a hit. I 
 am therefore thinking - why not apply the no-hijack rule throughout the 
 language?
 
 If one symbol leads to working code through two different lookups, an 
 ambiguity error would be issued. The only exception would be if one 
 symbol is scoped and the other is at module scope (for the reasons I 
 discussed in another post).
 
 I wonder to what extent this would break modular code, or foster more 
 intelligible code. With this rule in tow, A.B.this() would have to use 
 Base.x and this.outer.x to access the two x's.
 

Count my vote in favor of this change. -- Auria
Oct 02 2009