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/lqlllioynzfmpaozw...@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'.
