June 22, 2022

On Wednesday, 22 June 2022 at 13:08:44 UTC, claptrap wrote:

>

On Wednesday, 22 June 2022 at 11:23:47 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 22 June 2022 at 11:01:27 UTC, claptrap wrote:

>

On Wednesday, 22 June 2022 at 08:16:26 UTC, Ola Fosheim Grøstad wrote:

>

It is useful when building your model. That is too obvious a point to argue: Start out by making everything maximally constrained, then loosen up (reluctantly) when you have no other option.

  1. Nobody does that.

Wrong.

What do you mean by "maximally constrained"?

It means that you make everything hidden outside the scope, it also means using const, don't apply shared etc etc.

Basically, it means you start out providing minimal access both within the module and externally.

Then, when you find that yo need to do something that requires direct access (e.g. compare and swap) you give just enough access to enable that.

Sometimes you might want to not provide direct access, but create a new accessor-class that is given privileges (e.g. a smart-pointer).

June 22, 2022

On Wednesday, 22 June 2022 at 08:16:26 UTC, Ola Fosheim Grøstad wrote:

>

It is useful when building your model. That is too obvious a point to argue: Start out by making everything maximally constrained, then loosen up (reluctantly) when you have no other option. The resulting model will be much better than if you just can change things from the outside. The reason for this is that good encapsulated code will produce a higher line count, and most programmers aim for a low line count (subconsciously or deliberately).

I don't think this is obvious at all. Assuming you and I were extremely intelligent, we wouldn't need any of that? We could keep the whole state of the whole program in our mind and manipulate it with ease.

But we aren't. We are just dumb monkeys. So we build abstractions under which we hide part of the complexity of the world we are dealing with and present it through a simplified API. This allow our monkey brain to do more because we can temporarily forget many aspect of the problem at hand.

But this comes at a cost. Typically, component A wasn't available from B, so the team in charge of B ends up making a different one that works how so slightly differently rather than depend on A (mind you, they may even now know that A exist at all, or have any sensible way to discover that fact), and now the end result is worse because there are two thing that do A in a slightly different way. Casey Muratori demonstrate that effect using the volume slider in windows here: https://www.youtube.com/watch?v=5IUj1EZwpJY&t=2054s (see timestamp, but the whole presentation is very much worth a watch).

So what is the barrier we put in place for our monkey brain when we use private? We state that the private thing is an implementation detail, and that whoever is using our interface shouldn't have to know about it. It leaves space in their brain for something else, which is more important for them to solve the problem at hand - at least, this is the assumption we make.

But here, we see the whole bizarre of the current argument: if I want to isolate the user of my code from having to know of the implementation detail of my interface, then it logically follows that they don't belong in the same module, as the module is the unit of abstraction at which implementation happens.

The ask is fundamentally inconsistent in its motivations, and this is why the only argument we have for it so far all come in the form of "the holy scripture says so".

June 22, 2022

On Wednesday, 22 June 2022 at 08:01:12 UTC, forkit wrote:

>

Additionally, since its a volunteer commmunity, people will choose what they want to work on - so someone would actually have to 'volunteer' to implement it. I doubt that would be Walter, and in any case, he certainly has enough on his plate... for the forseeble future.....

Here you go: https://github.com/dlang/dmd/pull/14238

June 22, 2022

On Wednesday, 22 June 2022 at 15:40:35 UTC, deadalnix wrote:

>

But we aren't. We are just dumb monkeys. So we build abstractions under which we hide part of the complexity of the world we are dealing with and present it through a simplified API. This allow our monkey brain to do more because we can temporarily forget many aspect of the problem at hand.

You have have many reasons to do encapsulation. One is to separate the specced interface from the implementation. Another one is to reduce complexity in a project that is growing. Yet another one is to document and enforce which parts are subservient to other parts (also within a class). Yet another one is to prevent mistakes when doing dangerous things… etc…

However, if you want to support going from an evolved prototype to a solid model then it certainly is very useful to constrain types maximally. In that setting it isn't only an interface-issue, it is a tool for making sure that you tidy up the code base in a gradual, orderly and timely manner.

Tighter encapsulation also allows more safe evolution, which is closely related to going from prototype to final model.

There is a reason for why Smalltalk was favoured by some for evolutionary development.

>

But here, we see the whole bizarre of the current argument: if I want to isolate the user of my code from having to know of the implementation detail of my interface, then it logically follows that they don't belong in the same module, as the module is the unit of abstraction at which implementation happens.

I don't really think "module" is an abstraction, unless you use it as a singleton. It is more like a namespace, for organizing. Usually.

You can can use a module for organizing separating layers, in which case it is an abstraction mechanism, but I wouldn't say it generally is used for abstracting.

>

The ask is fundamentally inconsistent in its motivations, and this is why the only argument we have for it so far all come in the form of "the holy scripture says so".

No… tigher encapsulation is a tool that gives me more control for a wide variety of reasons.

June 22, 2022

On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:

>

[snip]

Here you go: https://github.com/dlang/dmd/pull/14238

+1

June 22, 2022
On Wednesday, 22 June 2022 at 15:40:35 UTC, deadalnix wrote:
>
> ...
> But here, we see the whole bizarre of the current argument: if I want to isolate the user of my code from having to know of the implementation detail of my interface, then it logically follows that they don't belong in the same module, as the module is the unit of abstraction at which implementation happens.
>
> The ask is fundamentally inconsistent in its motivations, and this is why the only argument we have for it so far all come in the form of "the holy scripture says so".

Well, programmers are users of their own code.

Other programmers are users of other programmers code.

This is true now, and it'll be true in the future.

A module should be able to handle more than one abstract data type.

But it can't. Because the module is THE abstract data type in D.

You cannot use a class to represent and abstract data type in D, unless it goes in it's own module.

How crazy is that??!!!??!!

June 22, 2022
On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:
> On Wednesday, 22 June 2022 at 08:01:12 UTC, forkit wrote:
>> Additionally, since its a volunteer commmunity, people will choose what they want to work on - so someone would actually have to 'volunteer' to implement it. I doubt that would be Walter, and in any case, he certainly has enough on his plate... for the forseeble future.....
>
> Here you go: https://github.com/dlang/dmd/pull/14238

+1

ballsy ;-)

maxhaton's comment is interesting "I don't think I've ever actually seen a bug that would've been fixed by this."

I refer maxhaton back to the seminal paper on the benefits of abstract data types:

Programming with abstract data types - Liskov and Zilles 1974

https://dl.acm.org/doi/pdf/10.1145/942572.807045

June 22, 2022
On Wednesday, 22 June 2022 at 18:31:38 UTC, jmh530 wrote:
> On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:
>> [snip]
>>
>> Here you go: https://github.com/dlang/dmd/pull/14238
>
> +1

btw.

Great initiative !!

Would I be able to do the below with this change?


class C
{
 private(this):
   int x;
   string str;

   void secretMethod(){}

 private:
   // Do I need some friends ??

 public:
  // interface

}

June 22, 2022

On Wednesday, 22 June 2022 at 22:18:46 UTC, forkit wrote:

>

Would I be able to do the below with this change?

Yes

June 22, 2022
On Wednesday, 22 June 2022 at 22:23:36 UTC, Dennis wrote:
> On Wednesday, 22 June 2022 at 22:18:46 UTC, forkit wrote:
>> Would I be able to do the below with this change?
>
> Yes

woohoo!

you've breathed new life into D!!!