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