`restricted` member variables

forkit forkit at gmail.com
Thu Jun 23 01:13:22 UTC 2022


On Thursday, 23 June 2022 at 00:58:34 UTC, Mike Parker wrote:
> On Thursday, 23 June 2022 at 00:31:52 UTC, forkit wrote:
>
>> the argument that you have access to the module, and accidents 
>> won't happen, or 'just don't do it', is nonsensical.
>>
>
> I never said accidents won't happen. In fact, I'm sure I 
> explicitly called this out as a real potential problem I see 
> with private-to-the-module (especially when multiple people 
> work on it). But I also noted that the same problem exists 
> *within* the class because you can access any private member 
> from any class method. There is absolutely no practical 
> difference here.

It's just a matter of scale.

Big long classes, and you're back in the same problem area.

But with private(this), you can put small, closely related, 
user-defined types, in the same module, and never have to worry 
about mistakes. Not ever. Not by you, and not by anyone else.


> One of the Effective Java books (IIRC, might have been a 
> different book) pointed this out. If multiple methods modify a 
> private member, then you can't maintain an invariant on that 
> member. Java doesn't have built-in support for invariants like 
> D. The recommended solution? Always modify members through a 
> setter. But according to you, that's a problem because 
> accidents can happen.
>

It's a matter of scale.

The smaller the scope, the easier it is to identify 'mistakes'.

I'd rather find that mistake in the definition of the class, then 
on line 1050 down the module, where some 'free' function is doing 
something I didn't anticipate (i.e. a mistake).

>
> In D, the `invariant` feature allows you to maintain the 
> invariants of any class from within the class. A class in its a 
> module by itself is fully 100% encapsulated and the invariants 
> are guaranteed. So if you have invariants you don't want 
> violated, then put that class in its own module.

Walter is already on the record as saying this is an unreasonable 
constraint to impose. Has he changed his view?



More information about the Digitalmars-d mailing list