OT: Programming Expansibility

[Idan Arye via Digitalmars-d]

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.