On Monday, 13 June 2022 at 01:07:07 UTC, Mike Parker wrote:
> On Sunday, 12 June 2022 at 23:15:30 UTC, forkit wrote:
>> On Sunday, 12 June 2022 at 14:56:53 UTC, Mike Parker wrote:
>>>
>>
>> It takes a certain amount of ' ?? ' (not sure of the right word to use here) to not be surprised, when you're new car arrives and you're told "only brakes on the rear are necessary in this car", when you're experience is, that brakes on all wheels are more likely to protect you from an accident.
>
> The ?? is that you think this is a relevant analogy.

let's forget analogies!

how about two questions on your end of semester exam instead:

Withing a module:

(1) What is the disadvantage of having an 'optional' access modifier, such as 'class private', so that you can separate interface from implementation?

(2) what is the disadvantage in leveraging the compiler to help us in determining whether code outside that class, but within the same module, is correctly using that interface?

On Monday, 13 June 2022 at 02:29:54 UTC, zjh wrote:
> On Monday, 13 June 2022 at 02:24:49 UTC, zjh wrote:
>
>> Now, anyone can step in.
>> Just like you drive car,but you can also fly a plane, because we are all `friends`!
>
>
> They forgot what they were proud of, that is, they are professional.
> Then they allow `unprofessional outsiders` to sabotage `your professional`.
> Because we are all `friends(enemies)`!

I'm not convinced you're progressing this argument any better than i am with my analogies ;-)

Let's keep it a little more focused... perhaps?

On Monday, 13 June 2022 at 02:42:52 UTC, forkit wrote:

> Withing a module:
>
> (1) What is the disadvantage of having an 'optional' access modifier, such as 'class private', so that you can separate interface from implementation?
>
> (2) what is the disadvantage in leveraging the compiler to help us in determining whether code outside that class, but within the same module, is correctly using that interface?

That's backwards. You're talking about adding a new language feature. The bar in that case is to show that the new feature provides an advantage over the status quo, such that the additional complexity is justified.

That's what this boils down to. Walter and Atila are who you need to convince. Not me.

I just don't see *practical* advantage to it. Let's say I have this class using a shiny new `private(intern)` feature implemented by someone on my team.


```d
class Foo {
   private(intern) x;
}
```

Now I want to add a function in the module that manipulates `x`.

```d
void newFunction(Foo f) {
    f.x = 10;
}
```

Oops! Can't do that. But no problem. I have access to the source. I can change `x` to `private` so that I can access it everywhere in the module. Or I add a new `private(intern)` member function to set the value of `x` in the way I need it.

This is the reason I think it's a useless feature. If you have access to the module, you have access to the internal members of the class. It's no different than having a class per file in Java. At some point, it comes down to coding conventions (e.g., all internal access to private members within a Java class must explicitly go through the public interface).

How does this feature bring any benefit that can't be had by putting `Foo` in a separate module? That's the question you have to answer.

On Monday, 13 June 2022 at 03:46:52 UTC, Mike Parker wrote:

> How does this feature bring any benefit that can't be had by putting `Foo` in a separate module?
The issue here is that you can only have one module per file. Allow multiple modules per files and the motivation behind "private for this class" will be satisfied.

-Alex

On Monday, 13 June 2022 at 03:46:52 UTC, Mike Parker wrote:
> On Monday, 13 June 2022 at 02:42:52 UTC, forkit wrote:
>
>> Withing a module:
>>
>> (1) What is the disadvantage of having an 'optional' access modifier, such as 'class private', so that you can separate interface from implementation?
>>
>> (2) what is the disadvantage in leveraging the compiler to help us in determining whether code outside that class, but within the same module, is correctly using that interface?
>
> That's backwards. You're talking about adding a new language feature. The bar in that case is to show that the new feature provides an advantage over the status quo, such that the additional complexity is justified.
>
> That's what this boils down to. Walter and Atila are who you need to convince. Not me.
>
> I just don't see *practical* advantage to it. Let's say I have this class using a shiny new `private(intern)` feature implemented by someone on my team.
>
>
> ```d
> class Foo {
>    private(intern) x;
> }
> ```
>
> Now I want to add a function in the module that manipulates `x`.
>
> ```d
> void newFunction(Foo f) {
>     f.x = 10;
> }
> ```
>
> Oops! Can't do that. But no problem. I have access to the source. I can change `x` to `private` so that I can access it everywhere in the module. Or I add a new `private(intern)` member function to set the value of `x` in the way I need it.
>
> This is the reason I think it's a useless feature. If you have access to the module, you have access to the internal members of the class. It's no different than having a class per file in Java. At some point, it comes down to coding conventions (e.g., all internal access to private members within a Java class must explicitly go through the public interface).
>
> How does this feature bring any benefit that can't be had by putting `Foo` in a separate module? That's the question you have to answer.

In your example, there is no benefit. There is only a couple of lines of code in the module. I can chunk the whole module almost in one go.

That approach is not scalable because: first, humans decipher information using chunks, and second, humans make mistakes.

The argument that you have access to the source file is a strawman.

The one-class-per-file is also a strawman.

Why not one struct per file, one enum per file, one function per file, one int per file ... why only a class-per-file?

This is not about this approach or that approach.

It's about giving the programmer an option to decide which approach is best for them.

Your side of the argument is basically saying we don't want to give you that option - cause we know what approach is best for you.

On Monday, 13 June 2022 at 04:09:12 UTC, 12345swordy wrote:
> On Monday, 13 June 2022 at 03:46:52 UTC, Mike Parker wrote:
>
>> How does this feature bring any benefit that can't be had by putting `Foo` in a separate module?
> The issue here is that you can only have one module per file. Allow multiple modules per files and the motivation behind "private for this class" will be satisfied.
>

Right now, you can split your module into two files and present them to the world as a single module with package.d. What does your suggestion buy us that this doesn't aside from a single module name trait?

On Monday, 13 June 2022 at 04:39:23 UTC, Mike Parker wrote:
> On Monday, 13 June 2022 at 04:09:12 UTC, 12345swordy wrote:
>> On Monday, 13 June 2022 at 03:46:52 UTC, Mike Parker wrote:
>>
>>> How does this feature bring any benefit that can't be had by putting `Foo` in a separate module?
>> The issue here is that you can only have one module per file. Allow multiple modules per files and the motivation behind "private for this class" will be satisfied.
>>
>
> Right now, you can split your module into two files and present them to the world as a single module with package.d. What does your suggestion buy us that this doesn't aside from a single module name trait?

a choice.

On Monday, 13 June 2022 at 04:59:09 UTC, forkit wrote:
>
> a choice.

oh. I misread the question.

I don't want multiple modules per file.

Multiple files per module would be nice though.