digitalmars.D - generalizing hiding rules
- Andrei Alexandrescu (31/31) Oct 02 2009 I was just playing with some nested classes:
- bearophile (4/8) Oct 02 2009 I agree that making D tidier in such regards is positive, helps avoid er...
- Marianne Gagnon (3/18) Oct 02 2009 Count my vote in favor of this change.
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
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
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