Is defining get/set methods for every field overkill?


Wed Nov 23 22:26:37 UTC 2022


On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote:
> On Wednesday, 23 November 2022 at 11:06:12 UTC, []() {}() wrote:
>> On Wednesday, 23 November 2022 at 09:51:46 UTC, 
>> FeepingCreature wrote:
>>>
>
>> Why then should a programming language insist that all other 
>> code in the module should be able to bypass my specification, 
>> and do as it pleases to my type?
>>
>
>
> Please let's not repeat previous topics
>
> `private` will be enforced at module scope, for better or for 
> worse, there has already been a [1000 post 
> thread](https://forum.dlang.org/post/lqlllioynzfmpaozwbfj@forum.dlang.org) that resulted in basically nothing except someone creating a `private this` pull for curiosity that will never be accepted in the language
>
> Look at the very last post where the moderator had to 
> externally kill the thread to prevent it from being 
> revived/argued further

I wasnt discussing private, and it's rather off the point 
somewhat.

I was responding to the claims that were made in the blog that 
someone mentioned in this thread:

https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

The claim was, that Friends in C++ breaks encapsulation. But that 
is not correct. It merely expands the perimeter of that 
encapsulation by putting a door in the wall, along with a guard 
at the door. The encapsulation remains. The encapsulation itself 
is not enough however, hence the guard at the door.

And if you program classes 'as types' (whether you additionally 
do OOP or not - as that too is off the point), then coming to D 
and finding out that in the context of a module, your class is 
not even a type (because it simply has no perimeter at all in a 
module), then I cannot see how that enhances encapsulation, as 
was claimed in the blog. How can that possibly enhance 
encapsulation? That makes no sense.

If the blog were published in a journal.. well.. it would never 
get published in a journal ;-)

Critical analysis remains a great tool, even in relation to 
'blogs'.



More information about the Digitalmars-d-learn mailing list