Friends in D, a new idiom?

[IntegratedDimensions]

On Sunday, 27 May 2018 at 06:24:13 UTC, Vijay Nayar wrote:
> On Sunday, 27 May 2018 at 05:25:53 UTC, IntegratedDimensions 
> wrote:
>
>> Re: Friends in D, a new idiom?
>
> In D, there's no exact equivalent to friend, but there are a 
> few more specialized tools at your disposal. Normally all code 
> in the same module is essentially a friend, so if the classes 
> you are dealing with are tightly coupled, they can simply be in 
> the same module.
>

Yes, but this is not the case. I have two classes somewhat 
related but in different modules so I am looking for a more 
general solution. I do not like chunking everything in to the 
same module just to get around this type of problem.

> For example:
>
> module m;
>
> class C {
>   // This is still visible in the same module.
>   // See 
> https://dlang.org/spec/attribute.html#VisibilityAttribute
>   private int data;
>   ...
> }
>
> class CAccessor {
>   C _this;
>   this(C c) {
>     _this = c;
>   }
>   @property void data(int v) {
>     _this.data = v;
>   }
>   ...
> }
>
>> Initially I thought nested classes contained an inherent super 
>> but I guess that is not the case?
>
> Super is for inheritance rather than inner classes. So another 
> way to tackle your problem using super would be this:
>
> class C {
>   protected int _data;
>   @property int data() {
>     return _data;
>   }
> }
>
> class CAccessor : C {
>   @property void data(int v) {
>     _data = v;
>   }
>   C toC() {
>     return this;
>   }
> }

Yeah, but this is a bit bulky. Although maybe UFCS could work 
well in this case although one would end up requiring different 
names in modules rather than Access or Friend.

I haven't tried it but if UFCS allows a module function to access 
the protected member and outside the module the UFCS could be 
called. I think this might defeat the usage except I recently saw 
that UFCS can be called with = so they can emulate setters, so it 
might work well(until that syntax is depreciated).

>> I also imagine that one could enhance this so that write 
>> access could also be allowed by certain types.
>
> The 'package' visibility attribute can also be given a 
> parameter if you need to limit access only to certain module.
>

Yeah, maybe using packages is the best way to go. The modules I'm 
using are related so they could be used in a package. Doesn't 
help with the general case though.

>> Any ideas about this type of pattern, how to make it better, 
>> already exists etc?
>
> You might be looking for the "Builder Pattern" which uses a 
> separate object to construct and modify objects, and then it 
> creates a read-only object with those values upon request.

I'm looking for something lightweight and direct. It is not for 
total encapsulation control but to simply provide an extra level 
of indirection for write access to make the object look read only 
to those that directly use it.

Basically I have another class outside the module that needs to 
write to a variable in side an object to set it up, from then on 
it is read only. It can't be done at construction. Maybe their 
will be one or two other times that it will need to change but I 
don't see why I should have to expose it for anyone nor create a 
huge layer of complexity to allow for a single access. The method 
I gave works fine for this type of behavior and the UFCS probably 
will even be easier if it works.