Class views - a new concept

[bauss]

On Monday, 27 June 2022 at 12:00:58 UTC, Dom Disc wrote:
> 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
> }

Not so many @@@@@, D has enough attributes with it already. It's 
nothing but clutter.

On top of that 'access' would be better than 'sees' or something 
like 'with' as demonstrated below.

```d
class C
{
    hidden int x, y;

    avoid funA(int v) with (x)
    {
       x = v;
       y = 0; // error, no access
    }

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

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

```


But to be fair I don't really like this concept at all.

hidden, I'm okay with, anything more is just too much clutter.