www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Friends in D, the easy way!

reply Mr.Bingo <Bingo Namo.com> writes:
These go in the module you want allow access to the outside world 
just as if they were in the same module!

auto Setter(string name, alias O, T)(T t)
{
	mixin("t."~name~" = O();");
}

auto ref Getter(string name, T)(T t)
{
	mixin("return t."~name~";");
}



x.Setter!("privateFieldName", { return value; }); // 
privateFieldName = value;
x.Getter!("privateFieldName"); // = privateFieldName


You can think me now... or later, which ever you choose! I hope 
there is no SOLID henchmen here!

Of course, these should be used only between modules that are 
tightly coupled... This can happen when a derived class needs 
access to it's parent as if it were in the same module but the 
modules are split only for parsing.
Jun 17 2018
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote:
 These go in the module you want allow access to the outside 
 world just as if they were in the same module!

 auto Setter(string name, alias O, T)(T t)
 {
 	mixin("t."~name~" = O();");
 }

 auto ref Getter(string name, T)(T t)
 {
 	mixin("return t."~name~";");
 }



 x.Setter!("privateFieldName", { return value; }); // 
 privateFieldName = value;
 x.Getter!("privateFieldName"); // = privateFieldName


 You can think me now... or later, which ever you choose! I hope 
 there is no SOLID henchmen here!

 Of course, these should be used only between modules that are 
 tightly coupled... This can happen when a derived class needs 
 access to it's parent as if it were in the same module but the 
 modules are split only for parsing.
Looks like it would be very verbose and honestly I'd rather see an approach where the private fields has a public exposure through a function or something. It looks much cleaner IMO.
Jun 18 2018
parent Mr.Bingo <Bingo Namo.com> writes:
On Monday, 18 June 2018 at 07:24:47 UTC, bauss wrote:
 On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote:
 These go in the module you want allow access to the outside 
 world just as if they were in the same module!

 auto Setter(string name, alias O, T)(T t)
 {
 	mixin("t."~name~" = O();");
 }

 auto ref Getter(string name, T)(T t)
 {
 	mixin("return t."~name~";");
 }



 x.Setter!("privateFieldName", { return value; }); // 
 privateFieldName = value;
 x.Getter!("privateFieldName"); // = privateFieldName


 You can think me now... or later, which ever you choose! I 
 hope there is no SOLID henchmen here!

 Of course, these should be used only between modules that are 
 tightly coupled... This can happen when a derived class needs 
 access to it's parent as if it were in the same module but the 
 modules are split only for parsing.
Looks like it would be very verbose and honestly I'd rather see an approach where the private fields has a public exposure through a function or something. It looks much cleaner IMO.
Doesn't matter, sometimes that just isn't the approach. Back in the day I learned very quickly that if I had a star peg that it wouldn't fit in the square hole so I found the star hole and magically it worked like a charm! I learned from that day on that it's not just the peg but also the hole! Fortunately I'm a fast learner...
Jun 18 2018
prev sibling parent Gary Willoughby <dev nomad.uk.net> writes:
On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote:
 These go in the module you want allow access to the outside 
 world just as if they were in the same module!
See the package attribute: https://dlang.org/spec/attribute.html#visibility_attributes
Jun 18 2018