On Friday, 23 October 2015 at 05:17:47 UTC, Jeffery wrote:
Oh, Well, I don't think it is arbitrary. If you expose a public
member, then you are not encapsulating it and exposing it to
the public.
The compiler does know this. Hence adding any wrapper does not
change the encapsulation.
My point is that automatically wrapping every method of the
public fields makes the wrapping pointless. Your idea seems to me
like sugar around the Law of Demeter. But the point of the Law of
Demeter is not to reduce the number of dots per expression - it's
to force interactions with the inner objects of a composition to
be done via methods of the outer objects. By automatically
exposing all methods of the inner objects via wrappers you are
missing the entire point of LoD - even if user code can do
`yours.foo()` instead of `yours.m.foo()`, it still interacts with
`yours.m` without any meaningful mediation of `yours`.
If x is a public field of a class, then how can wrapping it
hurt anything. If you expose the internal public members of
x(if any), then this might create less encapsulation than you
want. If you want to hide some public members of x then surely
it is not hard to inform the compiler to do so? Explicitly
marking the public members of x you want to hide should be easy
enough:
public class X
{
public void foo();
}
public class A
{
public X x;
private x.foo; // Marks x as private so compiler does not
implement wrapper for x.foo
}
(of course, better notations would exist).
Essentially the logic is "wrap by default". Since most of the
time the programmer is creating wrappers, this seems it would
save a lot of work?
Unless there is a good reason to do otherwise(a good reason is
something like to-not-break-existing-code, not something like
to-save-some-typing) the default should be the more restricting
option. Programmers will add the extra syntax to lift the
restriction when the actually need it removed, but they usually
won't bother to add the restriction when their code works
perfectly fine without it.
