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.

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.

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...

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