On Friday, 10 June 2022 at 23:36:48 UTC, H. S. Teoh wrote:
>
> ...
> 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.

People can interact, and nothing need to get mutated.

If they're all stubborn in their views, then it's likely nothing can be mutated anyway. In this case, interaction and mutation are mutually exclusive.

In the same way, I want to protecting my class from mutation (making it stubborn to being mutated by the outside world). My class will decide when to mutate, and when not to mutate. My module should not force mutation on me.

On Saturday, 11 June 2022 at 00:33:27 UTC, H. S. Teoh wrote:
>
> ..
> IMO, in spite of all its flaws and dark corners, D strikes a good balance between "academic" design and pragmatic enterprise-style code.
>
>
> T

I'm not necessarily rejecting your assertion, but can you elaborate please.

A good balance of what? And for what purpose?

On Sat, Jun 11, 2022 at 12:25:08AM +0000, forkit via Digitalmars-d wrote: [...]
> In OOP, the primary unit of scope/encapsulation is the class.
> 
> I'm not aware of there being different views on this matter - but happy to be enlightened.
>
> That is the basis on which I reject the assertion that D is a better OO language.

OK, you got me there. :-D  But the person you were replying to *did* clarify that what they meant by "OO" is "encapsulation, separation of concerns".  So not necessarily OO in the strict sense of the word.


> btw. I'm not a proponent of Java, as some have suggested ;-)
> 
> So using Java to rebutt my argument, is pointless ;-)

"Without geometry, life would be pointless..."

Sorry, wrong forum. :-P


> But I do think, programming language of the future need to default to immutability and memory safety. One should have of course, the option, to opt-out where that is needed and appropriate.

Memory safety -- definitely agreed. Just browsing the latest list of CVEs one can't help noting that a disproportionately large number of them come from memory safety flaws.  It may take another decade or four, but languages that are unsafe by default will IMO eventually become obsolete.

Immutability -- not so much.  Maybe something like Rust's `var` to ask for mutability might work, but Haskell-style straitjacketed immutability isn't my cup of tea.


> The problem with D, is that it set out to be a betterC, perhaps even a betterC++.
> 
> But when one sets out to design a better motorcycle, you don't end up with a motorcycle at all. You end up with something completely different.
> 
> The advantage of a motorcycle, is you can just jump on it a zoom off......  and of course, you have the rush of being in control of your own fate..
> 
> That's the advantage of the motorcycle. Safety issues were never a primary consideration - otherwise you wouldn't be on that motorcycle.
> 
> So designing a better C or C++ is a futile effort, that results in some strange hybrid of things.. that don't see to really go all that well together.
> 
> I don't want a seat-belt on my motorcycle.
> 
> I don't want the seat-belts taken out of my car either.

But but... *I* want car-torcycle with half-length seatbelts that come off automatically when I'm getting on or off, but stay firmly on in the case of an accident!  Why can't I have both?  :-P  Surely with DbI and the appropriate UDAs, and perhaps an undocumented -preview=seatbelt switch or three, that could be made to work...!


T

-- 
People tell me that I'm skeptical, but I don't believe them.

On Friday, 10 June 2022 at 23:36:48 UTC, H. S. Teoh wrote:
>
> [...]
>> 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

C'mon. Please don't do that.

Here is what I actually wrote:

---
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.

Mutabilty is certainly 'convenient', and oftne necessary, especially in low-level code, but it needs to be approached with greater caution than is what demonstrated in D's source code.
---

On Sat, Jun 11, 2022 at 12:37:17AM +0000, forkit via Digitalmars-d wrote:
> On Friday, 10 June 2022 at 23:36:48 UTC, H. S. Teoh wrote:
> > ...
> > 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.
> 
> People can interact, and nothing need to get mutated.
> 
> If they're all stubborn in their views, then it's likely nothing can be mutated anyway. In this case, interaction and mutation are mutually exclusive.
> 
> In the same way, I want to protecting my class from mutation (making it stubborn to being mutated by the outside world). My class will decide when to mutate, and when not to mutate. My module should not force mutation on me.

You know how ridiculous that sounds, right? -- when you rephrase that in terms of a different unit of encapsulation.  "I want to protect my function's per-object state from mutation by other functions in the class.  My function will decide when to mutate, and when not to mutate. My class should not force mutation on me."  Or, "I want to protect my local variables from mutation by other blocks in the function. My block will decide when to mutate, and when not to mutate.  My function body shold not force mutation on me."

One can argue that functions in a class ought to work together on that class's data; one could argue the same for functions (and other code) in a module. Or blocks in a function.  It's essentially the same argument at the core; the only difference is the unit of encapsulation.

As I said, opinions differ on this.  You say the class ought to be unit of encapsulation, Walter says it should be the module. Maybe next week I should write a DIP arguing for the block to be the unit of encapsulation instead.  Each side of the argument has its merits and demerits; the choice is essentially arbitrary, based on what the language designer deems more important or not, in balancing the tradeoffs in the language.

There are bigger fish to fry in the pond of programming language design.


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy

On Saturday, 11 June 2022 at 00:48:29 UTC, H. S. Teoh wrote:
>
> But but... *I* want car-torcycle with half-length seatbelts that come off automatically when I'm getting on or off, but stay firmly on in the case of an accident!  Why can't I have both?  :-P  Surely with DbI and the appropriate UDAs, and perhaps an undocumented -preview=seatbelt switch or three, that could be made to work...!
>
>
> T

D makes a great car-torcycle. I'll give you that ;-)

I see plenty of teenagers in my street, driving strange looking hybrids up and down the street. They love it too.

But I don't wanna drive interstate using one of those.

Happy to drive around the streets though.

On Saturday, 11 June 2022 at 01:00:44 UTC, H. S. Teoh wrote:
>
> ..
> You know how ridiculous that sounds, right? -- when you rephrase that in terms of a different unit of encapsulation.  "I want to protect my function's per-object state from mutation by other functions in the class.  My function will decide when to mutate, and when not to mutate. My class should not force mutation on me."  Or, "I want to protect my local variables from mutation by other blocks in the function. My block will decide when to mutate, and when not to mutate.  My function body shold not force mutation on me."
>
> One can argue that functions in a class ought to work together on that class's data; one could argue the same for functions (and other code) in a module. Or blocks in a function.  It's essentially the same argument at the core; the only difference is the unit of encapsulation.

Any argument taken to the extreme, will certainly sound ridiculour - as you've demonstrated.


>
> As I said, opinions differ on this.  You say the class ought to be unit of encapsulation, Walter says it should be the module. Maybe next week I should write a DIP arguing for the block to be the unit of encapsulation instead.  Each side of the argument has its merits and demerits; the choice is essentially arbitrary, based on what the language designer deems more important or not, in balancing the tradeoffs in the language.
>
> There are bigger fish to fry in the pond of programming language design.
>
>
> T

In OOP, opinions do not differ on the level of encapsulation. It is the class.

I'm happy to be corrected here, if I'm wrong.

It's why it's called OOP, not MOP.

My only disagreement is where a language offering OOP, goes and puts this principle aside.

It's not a disagreement in the module being an abstraction that provides a barrier around it. It's that the module swallows up the barrier of the class.

Therefore, is you use classes in D, the very principle of OOP has been 'mutated'.

In my case, I'm protecting this principle, it's private, and I mean really private, and the outside world is not going to mutate it   .. I even have barriers in memory to prevent that from happening. So no amount of hacking will circumvent that barrier ;-)   .. but I'm sure many will keep trying.

On Saturday, 11 June 2022 at 01:00:44 UTC, H. S. Teoh wrote:
>
> .. As I said, opinions differ on this.
> You say the class ought to be unit of encapsulation,
> Walter says it should be the module.

No. This is not my argument. It never has been.

To use yet another analogy (but not taken to it's extreme though):

Think of the module as a house.

Now think of it as a house *without* doors inside it - no barriers - anyone can go anywhere.

Now consider what happens as you increase the number of people living in it, beyond one.

Very quickly, even at a small number, you start to realise that hey, maybe we need a door here, or over there.

But tough luck. Cause this house does not accomodate doors.

If you want even the most modest level of privacy, you need to go build your own house.

What I like to do, is put rooms in my house. Cause we're a family, and we like living together - but some of us really do want a reasonable, modest level of privacy - without having to go build our own house.

Consider the class, as being the door that provides that.

On Saturday, 11 June 2022 at 02:01:19 UTC, forkit wrote:
>

.. and Walter's response would be:

No. There are no doors in this house. It's not designed to accomodate doors.

On Saturday, 11 June 2022 at 02:07:04 UTC, forkit wrote:
>

of course, a door itself, won't do very much unless I also have walls.

Consider the walls, as the compiler 'enforcing' you to go through the door.

We got no doors, and no walls, in D.