| |
| Posted by H. S. Teoh in reply to forkit | PermalinkReply |
|
H. S. Teoh
Posted in reply to forkit
| On Fri, Jun 10, 2022 at 10:44:25PM +0000, forkit via Digitalmars-d wrote:
> On Friday, 10 June 2022 at 20:59:38 UTC, mw wrote:
[...]
> > D is supposed to be a better OO language (read: encapsulation,
> > separation of concerns), [...]
[...]
> Nonsense. D .. a better OO langauge??
This makes me chuckle. So the OO bandwagon is still alive and tooting, after all these years.
[...]
> The D module is designed to encourage shared mutability. There are no means to specifiy, let alone verify and enforce, encapasulated object invariants. They have no 'boundary' inside a D module - by that I mean, any other code in the same module can transgress any boundary that has been specified.
Interesting. By the same logic, any code in the same class in, say, Java, can "transgress any boundary" and omg modify shared state touched by other code in that class -- oh the horrors!
The only pertinent difference, really, is the size of the unit of encapsulation in which this is permitted to happen. For any non-trivial code to work at all, it has to interact with other code *somehow*. One part of the program has to share data with another part of the program, otherwise it might as well do nothing at all.
One may, of course, disagree with the chosen unit of encapsulation, but that's all there is to it, a difference in units. It isn't as though the universe is in danger of imploding as soon as shared state leaks beyond the boundaries of a(n) {expression, function body, class, module, thread, etc.}. It's a matter of balancing between risk and bureacracy: the larger the unit, the higher the risk; but the smaller the scope, the more the bureacracy (when you need to cross boundaries). I think almost all of us agree that there has to be *some* unit of encapsulation, we just disagree on what that unit should be.
[...]
> Co-operative mutability, is a major source of bugs - always has been, always will be (cause it makes it so difficult to reason about code).
>
> Mutable state subverts encapsulation, makes it more difficult to reason about code, and makes it difficult to scale 'correct' code.
[...]
This sounds like a sales pitch for Haskell. :-P The logical conclusion of the above line of reasoning is to eliminate mutable state altogether, and for that, Haskell perfectly fits the bill.
T
--
If it tastes good, it's probably bad for you.
|