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.
