On Thursday, 23 June 2022 at 01:27:23 UTC, Mike Parker wrote:
>
> https://dlang.org/spec/class.html#invariants
>
> A class in its own module can fully maintain its invariants, even when multiple methods modify a variable. Every function call is bookended with the invariant check.
>
> ...

Well, the 'invariant' statement in D, is interesting, but no replacement for strong typing.

I'm comfortable in saying, that a generally accepted central principle of good design, for a strongly typed abstract object, is that it can protect, isolate, limit access to (.. whatever terms you wanna use) its internal representation, and thereby ensure any actions on it are limited to the actions that **it** defines.

An int type, is a simple, but clear example of this principle.

I cannot put "wtf" into an int.

private(this)  .. (or whatever syntax people are comfortable with), would ensure I can declare 'my own' strongly typed abstract object.

I now longer have to put that type in its own module, just to pretend its strongly typed.

My degree was in psychology, not computer science. But surely they teach this concept in computer science?

Or is this all new to D users?

On Wednesday, 22 June 2022 at 23:48:22 UTC, deadalnix wrote:
>> ```
>>
>
> This is a good starting point.
>
> Yes, Other will be able to manipulate VLA's innard in this exemple. Now there are two questions that immediately come to mind:
> 1/ Should it be able to? From this limited example, it's hard to tell, but there is no need to be pedantic so we'll assume that yes it does. You'll note that this is not obvious per so, Other might be a view on the VLA for instance.
> 2/ If 1/ is true, then do they really belong in the same module?
>
> I think 2/ is the question that is being skipped there, because the very characteristic of a module is to be the place where all the element it contains are implemented. If it is capital that Other is not exposed to the innard of VLA, then is it hard to defend that implementing them both together in the same place is the right design choice.
>

shouldn't 'what goes in a module' be the choice of the programmer?

why does it have to be something enforced on the programmer, by the language?

the problem with the D module, is that enforces on all programmers, that IT is THE MASTER abstract data type to rule them all, and all others shall bow to it.

Sorry, but no! My types will NOT bow.

In fact, not even an int in D bows to that demand. Why should my types?

On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote:

>
> Or is this all new to D users?

I was a Java programmer before I was a D programmer. I understand all of the OOP principles you've been bringing up in this discussion, as I'm sure everyone else does.

What I'm arguing is that those principles still hold in D. The difference between D and Java (or similar) is that in D, the boundary is at the module level, not the class level. Everything in the module is part of the private API. We've just expanded the definition of private API from "inside the class" to inside the module. Your types are still as strong, still as encapsulated, via the public API (outside of the module).

In Java, anything that shouldn't touch the private API of a class shouldn't be part of that class. In D, anything that shouldn't touch the private API of a class shouldn't be in the same module as that class. How are the two concepts any different?

This is what you've got to show. What is the *practical* problem that private-to-the-module causes that wouldn't be true if we had private-to-the-class (i.e., what can go wrong with the module as part of the private API that wouldn't go wrong if the same thing were done inside the class).

Yes, there's a problem in that invariants and mutex locks can be bypassed, but that's not a problem with the private API. The private API is allowed to touch that stuff. It's a problem because it violates the public API, i.e., external calls to module functions bypass the invariant and the mutex lock. That's a bug that can be fixed without a new protection attribute.

Arguments that encapsulation is broken in D because of private-to-the-module are purely ideological without a concrete example of a problem a new protection attribute would prevent. Yes, it's true that the class boundary is violated in the module. But because the module is part of the private API, that doesn't matter one bit.

On Thursday, 23 June 2022 at 04:34:03 UTC, Mike Parker wrote:
> On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote:
>
>>
>> Or is this all new to D users?
>
> I was a Java programmer before I was a D programmer. I understand all of the OOP principles you've been bringing up in this discussion, as I'm sure everyone else does.
>
> What I'm arguing is that those principles still hold in D. The difference between D and Java (or similar) is that in D, the boundary is at the module level, not the class level. Everything in the module is part of the private API. We've just expanded the definition of private API from "inside the class" to inside the module. Your types are still as strong, still as encapsulated, via the public API (outside of the module).
>

Well, I'm not sure strong is the right word here.

I think you mean, strongly enforced by something other than the type.

That is not the same as a strong type.

>
> Arguments that encapsulation is broken in D because of private-to-the-module are purely ideological without a concrete example of a problem a new protection attribute would prevent. Yes, it's true that the class boundary is violated in the module. But because the module is part of the private API, that doesn't matter one bit.

so, just to do simulate a strong type in D, I have to take this tiny little base class and put it in its own module?

Woohoo! It's 2022, and i can simulate a strong type in D.

So the problem here, since so many don't get it, is that I can only simulate a strong type in D, by putting that type in its own module.

That IS the problem. That is not the basis on which a language can claim to support OOP using classes!

module test;
@safe:

class Base
{
  private:
    int x = 100;

  public:
    int getX(){ return this.x;}
}

class Derived : Base
{
}

unittest
{
    import std;

    Derived d = new Derived();

    writeln(d.x); // oops. mistake.
                  // can't rely on the compiler here,
                  // its hasn't a clue what's going on.

    writeln(d.getX()); // using the public interface is cool.
}

On Thursday, 23 June 2022 at 04:34:03 UTC, Mike Parker wrote:
>
> ...
> Yes, it's true that the class boundary is violated in the module.

Oh. you just said it better than I ;-)

'the class boundary is violated in the module'.

D's claim to fame. I'm sure that will attract all those millions of OOP out there. They'll be banging down your door to get in, so they can start using D.

> But because the module is part of the private API, that doesn't matter one bit.

Umm. If it's not in the api of my class, then it shouldn't be in the api of my class.

Don't force your own api into my class. On what basis should i accept that?

Not only has the D module redefined the concept of a strong abstract data type, it's also trying to redefine the very basis of OOP (a strong abstract data type).

btw. Why won't the module let me put "wtf" into an int?

Oh. cause built in types are strongly typed. the compiler ensures its invariants are upheld. but your user-defined types do not get that privledge in D.

You can call it ideological, philosophical, or whatever, but I just cannot accept it.

A language that I use (outside of playing with it), must support the concept of a strong abstract data type. offering of a constraining workaround just to simulate one, is absurd.

On Thursday, 23 June 2022 at 05:09:17 UTC, forkit wrote:
>

gather around kids...

This is how encapsulation is achieved.

Each object is in charge of its own state.

Each object keeps that state private.

Other objects don’t have direct access to this state.

Instead, they can only call a list of public functions — called methods.

Now if your using the D programming langauge, this isn't the entire story. The rest of that story is in that big, black, scary book on the top shelf. In that book, you can make a cat bark, if you want. But we won't go there. It's too scary!

"How to explain object-oriented programming concepts to a 6-year-old"

https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/

On Thursday, 23 June 2022 at 05:41:19 UTC, Ola Fosheim Grøstad wrote:
>
> Stronger typing is desirable in complex performance oriented system level programming. This is the biggest weakness of C. Modules are clearly weaker than class/struct level protection. Weaker typing is not better in this context.
>
> But «private(this)» is inconsistent and ugly. Other languages being ugly is not a good excuse. Most fields should be marked class private and that makes this uglieness a burden.

Well, strong typing is the foundation of structured programming.

And structred programming is the foundation of scalable programming.

So I'd argue is more that 'desirable'. It's actually necessary.

Even Javascript has realised this recently. It's more powerful than D now, as far as strong typing goes! I never thought I'd say that...yeepers!

But really, the burden of typing this, just once in your class:

private(this):

seems pretty trivial to the burden of putting every class in its own module, just to simulate a strong type.

On Thursday, 23 June 2022 at 06:09:41 UTC, Ola Fosheim Grøstad wrote:
>
>
> My experience from C++ is that I end up with multiple «private:» to get the best structure.
>
> D needs to stop thinking that it can take just one more @ugly. Syntax matters.

well whatever the syntax.... it's a little irrelevant at such an early stage.

I'm using dkorpel's 'private-this' branch of dmd, and it's doing just what I want.

The world has not collapsed ;-)

https://github.com/dkorpel/dmd