Adding a new design constraint to D

[forkit]

On Saturday, 18 June 2022 at 17:38:21 UTC, deadalnix wrote:
>
> More importantly, modules are the unit of abstraction over 
> implementation. When I open a module, I see all the code that 
> implement everything that's in the module. If there is 
> something in there that I shouldn't see, then it shouldn't be 
> in the module.
>
> It's very simple really.

Modules are an ideal form of encapsulation for procedural like 
programming.

D makes for a nice language for procedural like progamming.

The problem is, D claims to support OOP, using classes -> "The 
object-oriented features of D all come from classes." - 
https://dlang.org/spec/class.html

However, when you put this claim to the test, you suddenly find 
there is no language mechanism to apply one of the most important 
principles in OOP, which is information hiding -> of course I 
mean this in the context of code within a module.

The idea that all data within a class is global to the module, 
and therefore mutable, by default, is inconsistent with the claim 
that D makes.

Worse even, there is no language option to change this, let alone 
enforce it (at compile time).

Information hiding is central to the concept of a concrete type, 
which in OOP, is what a class is -> a concrete type.

OK. So how do you apply the principle of information hiding in D. 
Well, you put the class that needs this, into it's own module.

Sure, you've now you've got a defacto means of hiding information 
(since there's no other code in the module) - but that comes at 
the cost of new design constraint that gets imposed on you (one 
class per module, always, just as a defacto means to make it into 
a concrete type).

But this is not OOP. Lets be really clear about this.

Therefore I find the claim, that D support OOP, to be.. dubious.

D clearly wants to be a procedural programming language, not an 
OOP.

I have no problem with that. All power to ya...

But please, don't make the claim that the language supports OOP, 
when it clearly is missing a language feature to allow a class to 
be a concrete type.

In OOP, private should be the default in classes, and it is 
usually the better choice (paraphrasing Stroustrup here).

This is why I only feel comfortable doing OOP in other languages, 
and not D.

The lack of a language feature to keep information private to the 
class (and enforce that design intention at compile time) , 
cannot be justified as just being a tradeoff. Rather, it was a 
design decision, made by Walter. It was a decision made for 
convenience, but at the expense of OOP.

Other languages that do support OOP, have not 'needed' to make 
this 'tradeoff' in order to get a cohesive language that can 
support OOP.