digitalmars.D - Friends in D, the easy way!
- Mr.Bingo (19/19) Jun 17 2018 These go in the module you want allow access to the outside world
- bauss (5/24) Jun 18 2018 Looks like it would be very verbose and honestly I'd rather see
- Mr.Bingo (7/39) Jun 18 2018 Doesn't matter, sometimes that just isn't the approach. Back in
- Gary Willoughby (3/5) Jun 18 2018 See the package attribute:
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
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
Mr.Bingo <Bingo Namo.com> 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: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...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
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