Class views - a new concept

forkit forkit at gmail.com
Mon Jun 27 21:39:51 UTC 2022


On Monday, 27 June 2022 at 12:08:27 UTC, bauss wrote:
>
> 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.

yes. after working through this idea some more, I found this is 
not such a good idea afterall ;-)

I still like the idea of enhancing D's invariant function, so i 
can do somethiing like this (see futher below).

i.e. in one tiny piece of code, I know what accesses these 
private member variables, and the compiler can statically 
demonstrate whether my code violates such invariants.

Here I use private(this), so being private to the class, only 
member functions can access it. But if it was 'private', it would 
be private to the module, and your invariant declaration could 
include 'free functions' (in the same module) as well.

Again, this idea too is not thought through to completion, but as 
yet, I don't see any red flags (in the idea itself).

class C
{
     private(this):
      int x, y, z;

     invariant()
     {
         // restrict certain member functions to certain member 
variables.
         assert( @restrictedMemberAccess {x, y : setXY, getX, 
getY};
     }

     setXY(int x, int y) { x = x; y = y } // fine
     int getX( return x); // fine
     int getY( return y); // fine

     void foo( x = 0; ); // noCanDo! foo is not in the above list.
     void bar( z = 0; ); // fine. no invariants declared. so 
normal rules apply.
}




More information about the Digitalmars-d mailing list