On Friday, 10 June 2022 at 22:44:25 UTC, forkit 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), and DMD is developed by a number of highly capable very experienced D developers (read: not ordinary programmers), how come DMD is in such a terrible state as if it's done by some average Joel (above)?
>>
>> No offense, I am just puzzled by this software engineering myth.
>
> Nonsense. D .. a better OO langauge??
>
> Do you even know how hard it is, to reason about a D module?
>
> The D module is, apparently, THE single most important abstraction for encapsulation - someone decided to design it this way.
>
> This conflicts with OO principle of being able to encapsulate an objects invariants in its specification. So D, a -betterOOP .. hah!

Welcome to single module per class. Really, I fail to understand what's the problem with having one class per module, and import multiple classes per module using public imports if you desire to import multiple classes at once.

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

Which sometimes is quite useful, otherwise you'd end up with static nested classes/structs...

> Please drop this idea, that D is a better OO langauge. It is not.

While it is not better per your reasoning, it is certainly not worse than others per my experience, and at least better than C++. I'd say on level with Java or a bit higher in functionality and convenience.

Best regards,
Alexandru.

On Saturday, 11 June 2022 at 10:49:09 UTC, Alexandru Ermicioi wrote:
>
> ..
> Welcome to single module per class. Really, I fail to understand what's the problem with having one class per module, and import multiple classes per module using public imports if you desire to import multiple classes at once.
>

The problem I have, is that a class is not considered a proper type in D.
If it were, you would be able to define and enforce (at compile time) its invariants. As it is, any code in the module (outside of the class), can invalidate the invariants.

This is equivalent to D letting you put "wtf!" into an int. Would you be happy with that?

i.e Even an int is given better type conformance in D.

The module is not a type!

I do not design my solution around the module. I design it around types, and I use the module to bring related types together.

Separate, unrelated types can go in their own module.

In the event a type (and I'm talking about an instatiation of class here) - is a standalone type.. sure..it can go it's own module, no problem. Makes sense even.

But you don't have to put every int your define into its own module, just so the compiler can enforce its invariants. That would be crazy.. yes?

A class is just a type - why is it considered less a type than an int? (i.e. the only way to protect its invariants, is to put it all by itself in its own module.

What utter nonsense!


> While it is not better per your reasoning, it is certainly not worse than others per my experience, and at least better than C++. I'd say on level with Java or a bit higher in functionality and convenience.
>
> Best regards,
> Alexandru.

The module is not a type. You do not design your solution using types.

You do not instatiate a module, and start sending it messages, or recieve messages from it, or change its behavior, or have it change its own behavior.

The module is a just convenient static encapsulation for related types.

but you design a program by using types, not modules.

On Saturday, 11 June 2022 at 11:24:04 UTC, forkit wrote:
>
> The module is not a type. You do not design your solution using types.
>

oops. of course the above should have said:

> The module is not a type. You design your solution using types.

On Saturday, 11 June 2022 at 08:57:40 UTC, forkit wrote:
> 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

I am well acquitted, thank you very much. It would have been a bad major in systems programming and languages, if I had missed such basic stuff.

Basically you are asserting that anything besides Simula isn't OOP, that is like asserting only pure lambda calculus is FP.

On Saturday, 11 June 2022 at 11:31:17 UTC, Paulo Pinto wrote:
>
> I am well acquitted, thank you very much. It would have been a bad major in systems programming and languages, if I had missed such basic stuff.
>
> Basically you are asserting that anything besides Simula isn't OOP, that is like asserting only pure lambda calculus is FP.

I think we're clearly talking two different things here?

me - object oriented languages (which support all of the features of object-oriented programming)

you - object based languages (which support a subset of the features of OOP)

we have to agree on terminolgy, or otherwise, its not possible to represent a concrete idea.

A bit like the D module, which can't agree on what is a type and what isn't  ;-)

On Saturday, 11 June 2022 at 11:42:06 UTC, forkit wrote:
>

btw.

I'm open to being enlightended, on how a language can support all the features of object-oriented progamming -  including, encapsulation, inheritance and polymorphism - without a class type.

My assertion was, that a language that supports OOP, must have a class type.

I'm not aware of another way to provide all these features without a class type.

Is there another way? Did you learn something in your degree that I'm unaware of?

On Saturday, 11 June 2022 at 11:32:52 UTC, zjh wrote:
> On Saturday, 11 June 2022 at 11:27:34 UTC, forkit wrote:
>
>>> The module is not a type. You design your solution using types.
>
>
> `Defeat` them, I support `you`!

I'm sure giving it my best shot ;-)

If I'm going to use a class type in D, then D needs to treat it at least as equally as an int type ;-)

i.e. If I put an invariant in my type, I expect the compiler to enforce it (at compile time).