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

Then don't use module to bring related types yet not tightly coupled ones toghether. Use rather packages. It seems that your definition of module is more matching to a package in D rather than D module.

It is indeed pain sometimes to have to create new modules, but you can argue that it is also pain to skim through thousands of lines of code in a single module.

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

Why not? Why crazy?

Usually a type (class/struct) is not just a single or two lines, but 10-20 at least. Imho it is perfectly fine to put them in single file. In java, that is how it is done, one file one public class.

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

Obviously you're comparing apples with grapes. int is a built-in type and certainly not a class or struct, although making the builtin-types and user defined ones have homogeneous rules mostly, would be beneficial.

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

Well, why can't it be?
You certainly can consider it being a singleton per thread, where global vars are it's internal state, and exported functions are the methods to class (module). Certainly it doesn't have inheritance and other OOP aspects, but saying that module is a bunch of related types only, is not right. Better to say, is that they are bunch of tightly coupled types, meaning that extracting one type into separate module most certainly would require the other types in module to be adjusted to the change (not by importing the new module, but actual code changes).

In summary, the current access modifiers, don't make oop programming in D in any way less powerful, than any other language with comparable oop features.

Best regards,
Alexandru.

On Saturday, 11 June 2022 at 11:50:46 UTC, forkit wrote:
> 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?

OOP doesn't imply being class based, SIGPLAN has enough information on the matter regarding programming languages taxonomy.

You can start with ECOOP Proceedings available from Springer Verlag.

However it is clearly a waste of my time trying to convince you otherwise.