| |
| Posted by forkit in reply to deadalnix | PermalinkReply |
|
forkit
Posted in reply to deadalnix
| 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.
|