Is defining get/set methods for every field overkill?


Tue Nov 22 20:36:51 UTC 2022


On Tuesday, 22 November 2022 at 10:10:48 UTC, Sergey wrote:
>
> Based on this (not too old) post the idea remains the same and 
> approved by Walter’s experience:
> https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
> I saw some posts at forum about private-class-scope, but 
> community of core-D is fine with module-unit approach I think.

In the interest of 'critical thinking', it's important to point 
out, that one of the persons in this thread agreeing with the 
one-sided rant in the video link in this thread, is a co-author 
of that article.

It also seems, that article is primarly discussing encapsulation.

Encapsulation is not enough, as I've pointed out in this thread.

In D, one can no longer provide a static specification of a class 
type, let alone rely on the compiler to assure you of the 
correctness of that specification, in relation to the code 
surrounding it). Rather, in D, one must always include all the 
code in the module as being part of the static specification of 
the class (and the same is true for how ever many classes you 
have in that module). Even another class could form part of the 
specification of another class in the same module, even though 
they are both concrete classes. Wow!

I'm sorry, but that makes no sense to me.

The designers of the other languages mentioned in that article, 
seem to have the same opinion.

Whatever happened to the principle of least priveledge in D?

Of course, if you're against the us of private, against the use 
of getters and setters, and against the use of classes, in D, 
then sure, I can fully understand the decision to completely 
remove the perimeter for a class type, and hence that article 
makes complete sense.

Regardless, I fully support the concept that people should always 
form their own opinion - even on matters as absurd as this ;-)




More information about the Digitalmars-d-learn mailing list