www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Shadowing member in inheritance hierarchy - why

reply Brother Bill <brotherbill mail.com> writes:
D language supports shadowing members, where the shadowed member 
has same name and different type on same type.

Why is this enabled, and when should one use this advanced 
technique?
Aug 08
next sibling parent Brother Bill <brotherbill mail.com> writes:
On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

 D language supports shadowing members, where the shadowed 
 member has same name and different type or same type.

 Why is this enabled, and when should one use this advanced 
 technique?
Aug 08
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

 D language supports shadowing members, where the shadowed 
 member has same name and different type on same type.

 Why is this enabled, and when should one use this advanced 
 technique?


Overload rules are probably more fundamental then your thinking. 
Theres a core idea that hidden under the name "overload set".

```d
import std;
void bar(int){"int".writeln;}
void bar(float){"float".writeln;}
ref bar(bool b){
   bool bar;
}
alias foo=bar;

void foobar(alias A)(){
   A(1);
   A(13.37);
   A=true;
}
unittest{
   foobar!foo;
}
```

whats foo? unhelpfully its an "overload set"; I have not seen a 
good explanation for what it is.
Aug 08
prev sibling parent reply user1234 <user1234 12.de> writes:
On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

 D language supports shadowing members, where the shadowed 
 member has same name and different type on same type.

 Why is this enabled, and when should one use this advanced 
 technique?


That's not considered as shadowing as you can distinguish the two 
members using a qualified access chain.

```d
class A {int m = 1;}
class B.A {float m;}

assert((new B).A.m == 1);
```
Aug 08
parent reply Brother Bill <brotherbill mail.com> writes:
On Saturday, 9 August 2025 at 01:33:03 UTC, user1234 wrote:

 On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

 D language supports shadowing members, where the shadowed 
 member has same name and different type on same type.

 Why is this enabled, and when should one use this advanced 
 technique?


 That's not considered as shadowing as you can distinguish the 
 two members using a qualified access chain.

 ```d
 class A {int m = 1;}
 class B.A {float m;}

 assert((new B).A.m == 1);
 ```


I understand that members of various levels can be distinguished.
What I don't understand is why one would use this technique.
Aug 08
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:

 On Saturday, 9 August 2025 at 01:33:03 UTC, user1234 wrote:

 On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

 D language supports shadowing members, where the shadowed 
 member has same name and different type on same type.

 Why is this enabled, and when should one use this advanced 
 technique?


 That's not considered as shadowing as you can distinguish the 
 two members using a qualified access chain.

 ```d
 class A {int m = 1;}
 class B.A {float m;}

 assert((new B).A.m == 1);
 ```


 I understand that members of various levels can be 
 distinguished.
 What I don't understand is why one would use this technique.


As a regular user you probably don't need it.

I use it for meta programming and some quirky C++ interop where 
things can't be directly translated, for example when mixing 
virtual and non-virtual functions in C++ base/children classes 
(can't overload by virtual in D).
This is just one of examples on learn forum some time ago that 
shows some quirks of c++ interop and how overload set is used to 
fix it.
https://forum.dlang.org/post/zmzzissfeqoqxojgprxy forum.dlang.org

Basically same approach can be used for example to nativize API 
of C-style OOP like one used in GTK to make it feel more D.
That's being said, it is mostly for making API look nice to the 
users.
Aug 08
prev sibling parent user1234 <user1234 12.de> writes:
On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:

 I understand that members of various levels can be 
 distinguished.
 What I don't understand is why one would use this technique.


I skipped that part of the question because I thought that the 
fact that it's not a shadowing case invalidates it.

To be frank the only time I've ever used that was with OOP and 
when a derived class introduced a derived instance of another 
class type:

```d
class Declaration {}
class StructDeclaration : Declaration {}

class TypeDeclaration {
     Declaration d;
     this(Declaration d){
         this.d = d;
     }
}

class TypeStruct : TypeDeclaration {
     StructDeclaration d;
     this(StructDeclaration d){
         this.d = d;
         super(d);
     }
}
```

So that whenever you work with a TypeDeclared or one of his 
derived class, you known that `d` is of the corresponding Type 
with a corresponding level of derivation.

Obviously in this case a system of overlapped field would have 
made more sense but that does not exist in D (never seen that 
elsewhere either btw).
Aug 08