On Friday, 3 June 2022 at 08:53:08 UTC, forkit wrote:
>

class myClass
{
    _really_private string _ID;
}

On Wednesday, 1 June 2022 at 12:24:23 UTC, Dukc wrote:
>
> ...
> Controlling the scope of encapsulation is rarely that critical, and if it is, it's easier to just put the class to it's own file.

Actually, controlling the scope of encapsulation is *critical* to managing complexity.

Due to everything within a module being a (C++ like) 'friend' to any class within that module, the ONLY way to manage the complexity of a D module, in the case where object oriented design is in play, is by doing what you say - put each class in it's own module.

Fine.

I'd like to audit the D source code, to see if that is actually what happens when programmers have access to the flexible, friendly, D module ;-)

Otherwise, encapsulation is compromised.

On Friday, 3 June 2022 at 09:02:17 UTC, forkit wrote:
> On Friday, 3 June 2022 at 08:53:08 UTC, forkit wrote:
>>
>
> class myClass
> {
>     _really_private string _ID;
> }

Perhaps something like:

```
class Foo
{
    private class string _id; // Private to the class
}
```

```
class Foo
{
    private module string _id; // Private to the module
    private int _number; // Same as "private module" since that's the default
}
```

Of course an equivalent to structs "private struct" could be added as well.

On Friday, 3 June 2022 at 10:20:08 UTC, bauss wrote:
> On Friday, 3 June 2022 at 09:02:17 UTC, forkit wrote:
>> On Friday, 3 June 2022 at 08:53:08 UTC, forkit wrote:
>>>
>>
>> class myClass
>> {
>>     _really_private string _ID;
>> }
>
> Perhaps something like:
>
> ```
> class Foo
> {
>     private class string _id; // Private to the class
> }
> ```
>
> ```
> class Foo
> {
>     private module string _id; // Private to the module
>     private int _number; // Same as "private module" since that's the default
> }
> ```
>
> Of course an equivalent to structs "private struct" could be added as well.

To add onto this:

This also has the advantage of having no breaking-changes, since old code will work just the same, but new code can leverage the control of what is private and to what.

There's no reason to change the default behavior of private, BUT having the ability to change the behavior when necessary is nice.

Some of D's decisions are far too black and white and forgot that there are nuances to programming.

On Friday, 3 June 2022 at 10:12:04 UTC, Guillaume Piolat wrote:
> On Friday, 3 June 2022 at 05:58:06 UTC, Mike Parker wrote:
>>
>> No, it's not sad.
>
> +1, not everything has to be decoupled.
> Being in the same file means you want those things to be coupled, and thus you get that.
> I much prefer that to the "friend" thing in C++.

Hey, it's fine that the D module is in effect 'the owner' of the representation of a class, rather than the class itself. While suprising to some, that's just how it is.

It's not a bad thing. There are benefits in that approach, and I am not arguing against that approach.

But in D, if you want to statically enforce class encapsulation, the *only* way you can do this, is by putting every every class in its own file.

That is what's sad.

> +1, not everything has to be decoupled.
+1 ;-)

> Being in the same file means you want those things to be coupled, and thus you get that.

Not necessarily. The overall goal should be encapsulation (hence in D, the one class per module recommendation). But the goal of encapsulation is to manage complexity and support local reasoning. It's not an excuse to force programmers to put each class in its own module, in order to statically enforce its represenation.

On Friday, 3 June 2022 at 10:37:28 UTC, forkit wrote:

>
> Not necessarily. The overall goal should be encapsulation (hence in D, the one class per module recommendation). But the goal of encapsulation is to manage complexity and support local reasoning. It's not an excuse to force programmers to put each class in its own module, in order to statically enforce its represenation.

And in D you encapsulate at the module level. We don't need another keyword for more fine-grained encapsulation, because we already have a solution in the form of the package module.

On Friday, 3 June 2022 at 11:50:22 UTC, Mike Parker wrote:
> On Friday, 3 June 2022 at 10:37:28 UTC, forkit wrote:
>
>>
>> Not necessarily. The overall goal should be encapsulation (hence in D, the one class per module recommendation). But the goal of encapsulation is to manage complexity and support local reasoning. It's not an excuse to force programmers to put each class in its own module, in order to statically enforce its represenation.
>
> And in D you encapsulate at the module level. We don't need another keyword for more fine-grained encapsulation, because we already have a solution in the form of the package module.

That's fine, if a module that contains a class, is nice and short, and only contains code that directly acts on that class, and no other code, whatsoever.

Otherwise the encapsulation 'could' be broken (i.e. mutations maybe occuring outside of your encapsulated representation), and you won't know unless you know ALL the code in that module (as it cannot be enforced statically by the compiler). It's up to the human to verify the correctness.

To just say the programmer owns the module, and therefore everything will be fine.. is naive.

Practically speaking, anyone that uses a class in D, must be put it in its own module - no exceptions.

On Friday, 3 June 2022 at 12:13:47 UTC, forkit wrote:

>
> Practically speaking, anyone that uses a class in D, must be put it in its own module - no exceptions.

That's just nonsense.