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

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

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

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

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

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

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

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.

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.

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

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

+1

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

Yes