On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear
wrote:
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker
wrote:
On Wednesday, 15 February 2023 at 01:16:00 UTC,
thebluepandabear wrote:
I think what you could say is that D lacks _encapsulation_
which is also an OOP concept. So D is partially OOP but not
fully OOP due to there being no encapsulation in the language.
D does not lack encapsulation, it's just that the unit of
encapsulation is the module. Everything private in a module is
encapsulated from the perspective of the public API.
If you really want to prevent anything inside a module from
accessing the private parts of a class, you can put the class
in its own module.
Must we continue beating this horse?
Why is the unit of encapsulation the module though? Makes no
sense.
It does make sense. But not if the language also provides
user-defined types. That is explained in the Stroustup paper I
cited.
That is, a language that provides modules as well as user-defined
types, should provided encapsulation for both. D does that, but
for user-defined types it doesn't in the context of other code in
the same module as that type. That is why in D you are 'forced'
to put that type in its own module 'just' to encapsulate it from
other code that would have otherwise been in the same module.
No. It makes no sense. A user-defined type should be able to
protect hidden data from other code within the same module. That
really doesn't sound that extreme to me ;-)
