On Saturday, 11 June 2022 at 02:01:19 UTC, forkit wrote:
> Think of the module as a house.
>
[...]
>
> 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.

I guess when you say "without having to go build your own house", you mean "without having to create a new file"? In other words, you would like encapsulation boundaries to be decoupled from file boundaries.

IMO the correct way to do this would be to simply allow multiple modules to be declared in the same file, rather than to couple encapsulation boundaries to class boundaries. This is a feature that has been requested many times for D, and one that several other languages have implemented successfully.

It is not entirely without downsides. Putting multiple modules in one file would complicate the build process somewhat--for example, `dmd -i` would no longer Just Work™ the way it currently does. But if someone could put together a convincing DIP, I think it's possible this feature could be added to D in the future.

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

Why thats quite an insult; neither academia or enterprise grade oo have any value.

On Friday, 10 June 2022 at 23:41:58 UTC, H. S. Teoh wrote:

> Wow, you're optimistic.  After having worked with "enterprise" code for the last how-many decades, I would rate 99% of non-trivial codebases out there somewhere between 0 to 1 on a scale of 1-10.
>
> If you think dmd is bad, wait till you see the code of an "enterprise" compiler for an "enterprise" language. I guarantee you, you will need therapy afterwards. :-P  To this day I still suffer PTSD from having once attempted to read glibc source code...
>

And at the same time, it looks like the D leadership revere "the industry" as a source of "best industry practices" we should adopt.

On Saturday, 11 June 2022 at 01:14:16 UTC, forkit wrote:
> 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.
>
> ...

Regardless of how it is called, OOP is definitely not the class.

There are no classes in prototype based OOP languages like SELF and JavaScript (the ES6 "class" gets desugared into prototypes anyway).

There are no classes in pattern based OOP languages like BETA.

There are no classes in type extension based OOP languages like Oberon.

There are no classes in multi-methods/protocol based OOP languages like Common Lisp, Clojure, Dylan and Julia.

There are no classes in interface based OOP languages like VB (pre-.NET), Go, Rust, OCaml.

Basically the OOP design space is big enough to have plain classes define the ultimate meaning of what is OOP.

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.

Class is *the* unit of encapsulation by any reasonable definition of class-based OOP. You don't create objects of modules (though modules can be viewed as singleton objects). You can argue about the mechanism of sharing the state between objects of different classes, but forcing the programmer to group classes together and share the entirety of their state is not the greatest of options.

Disclaimer: Ola may assume I see OOP as god, but I actually don't.

On Saturday, 11 June 2022 at 08:23:27 UTC, Max Samukha wrote:
>
> Class is *the* unit of encapsulation by any reasonable definition of class-based OOP. You don't create objects of modules (though modules can be viewed as singleton objects). You can argue about the mechanism of sharing the state between objects of different classes, but forcing the programmer to group classes together and share the entirety of their state is not the greatest of options.

+1

also, a class is a type, just like any other type - example an int.

when you assign to an int, type checking is done. you cannot put "wtf!" into an int! It has invariants to it, and the compiler checks these (type checking).

but for some reason, a class doesn't get the same protection - not even an option to protect it (from other code in a module).

The module is not a type, it's a unit of encapsulation, and that is all it is.

A class is a type, which is much more than just a unit of encapsulation.

When a class sets invariants, the compiler must do type checking, just as it does with an int, to ensure the invariants are being upheld.

When a programming langauges stops treating a class as a type, it cannot claim to have support for OOP.

On Saturday, 11 June 2022 at 07:27:43 UTC, Paulo Pinto wrote:
>
> Regardless of how it is called, OOP is definitely not the class.
>
> There are no classes in prototype based OOP languages like SELF and JavaScript (the ES6 "class" gets desugared into prototypes anyway).
>
> There are no classes in pattern based OOP languages like BETA.
>
> There are no classes in type extension based OOP languages like Oberon.
>
> There are no classes in multi-methods/protocol based OOP languages like Common Lisp, Clojure, Dylan and Julia.
>
> There are no classes in interface based OOP languages like VB (pre-.NET), Go, Rust, OCaml.
>
> Basically the OOP design space is big enough to have plain classes define the ultimate meaning of what is OOP.

When you redefine what an 'object' is, then anything can be OOP ;-)

Please properly acquaint yourself this this concept ;-)

http://kristennygaard.org/FORSKNINGSDOK_MAPPE/F_OO_start.html

On Saturday, 11 June 2022 at 07:27:43 UTC, Paulo Pinto wrote:
>
> ..
> Regardless of how it is called, OOP is definitely not the class.
>
> There are no classes in prototype based OOP languages like SELF and JavaScript (the ES6 "class" gets desugared into prototypes anyway).
>
> There are no classes in pattern based OOP languages like BETA.
>
> There are no classes in type extension based OOP languages like Oberon.
>
> There are no classes in multi-methods/protocol based OOP languages like Common Lisp, Clojure, Dylan and Julia.
>
> There are no classes in interface based OOP languages like VB (pre-.NET), Go, Rust, OCaml.
>
> Basically the OOP design space is big enough to have plain classes define the ultimate meaning of what is OOP.

Your forgot to mention the programming language called 17.

It doesn't use classes either.

But it's object oriented. Afterall, 17 is an object.