Class views - a new concept

[Dom Disc]

On Sunday, 26 June 2022 at 23:33:42 UTC, forkit wrote:
> So I came up with this idea, based on discussion in another, 
> rather controverial, thread ;-)
>
> In any case, I think this idea deserves it's own thread.
>
> NOTE::it's just an idea, and certainly **not** a proposal.
>
> I'd be interested to know, if anyone else out there knows of 
> any langauge, where a concept like this has been implemented 
> (i.e. a way to restrict specific class member functions to 
> specific class variables).
>
> So...here I introduce a new concept, which (for now), we'll 
> call a 'view'.
>
> It can solve multiple problems, at least for me.
>
> First, it eliminates a need for that very controversial idea of 
> 'private(this)'
>
> Second, it allows fine grained control of member access, to 
> member variables.
>
> Anything declared private, in a view, is simply private to that 
> view.
>
> Destroy! (but try to be civil too)
>
>
> class myClass
> {
>     @view
>     {
>         private:
>           int x;
>
>     	public:
>           void setX(int x) { this.x = x; }
>           int getX( return this.x; }
>     }
>
>
>     private:
>       void fred() { this.x = -1; }  // error: fred is not part 
> of the view that contains x
>       int waldo() { return this.x; } // error: waldo is not 
> part of the view that contains x
>
>     public:
>       void foo() { this.x = -1; }  // error: foo is not part of 
> the view that contains x
>       int bar() { return this.x; } // error: bar is not part of 
> the view that contains x
> }

What I don't like about this, is that free functions 
(non-members) can not be part of a @view. Also, this is nothing 
new. Instead of a @view you can simply use a subclass with static 
members (so that you don't need an instance of the subclass) and 
reach the same effect.

What part of "@hidden var" paired with "@sees(var) fun(){ }" 
don't you like? It provides the same features without needing 
extra scopes and also allow non-menbers to access @hidden vars if 
explicitly annotated.
Also it allows more fine-grained control:

class C
{
    @hidden int x, y;

    @sees(x) void funA(int v)
    {
       x = v;
       y = 0; // error, no access
    }

    @sees(x, y) void funB(ref int z)
    {
       int t = x;
       x = y; // ok
       y = z; // ok
       z = t;
    }
}

@sees(y) int funC() // a friend, because it's in the same module
{
    y = x; // error, no access to x, not even for reading
    return y; // ok
}