Is defining get/set methods for every field overkill?


Mon Nov 21 07:01:28 UTC 2022


On Sunday, 20 November 2022 at 12:23:39 UTC, Ali Çehreli wrote:
> ..
> Hm. 'private' is about access control. ....

It's unfortunate that phrase ('private') is used, both 
traditionally, and now (and yes, even by me).

A much better, clearer term, would be: 'interaction control', 
since that is what the programmer is really trying to achieve 
when inserting getters/setters into a class type.

i.e They are creating the specification for an encapulated object 
(data, and methods that operate on that data) with the necessary 
controls for 'interacting' with it.

On the otherhand, if the programmer is genuinely after 'access' 
control, then 'private' just won't do it ;-)

Also, D's 'arbitrary' changes, as mentioned in previous post, do 
not further progress the composition problem.

By that I mean, by enabling cooperative interactions within a 
module, D has also enabled potentially hazardous interactions as 
well, since you cannot enforce a perimeter around a class type 
from other code in the module. All code within a module, is 
within the bounds of that perimeter, at all times.

i.e. There is no way to enforce the principle of least privilege 
within a D module.

On that basis, I might be tempted to agree with you're point of 
view -> never, ever, ever, ever, use classes in D.



More information about the Digitalmars-d-learn mailing list