On Friday, 3 June 2022 at 15:41:04 UTC, Mike Parker wrote:
> 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.

It isn't nonsense if you want private to encapsulate to the class only and not the entire module file. That the technique that you *HAVE* to use in D. Unless you don't mind removing the one module per file restriction.

-Alex

On Friday, 3 June 2022 at 15:41:04 UTC, Mike Parker wrote:
> 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.

How is it nonsense? I don't get it.

If you want the compiler to statically ensure there are no unsafe mutations (from other code within the same module) on the encapsulated represenation of a class, then you have no choice (apart from *manually* inspecting and verifying all the code in the module).

You cannot get this static ensurance from the compiler otherwise.

The aim of class abstraction is to support encapsulation and local reasoning. The best way to achieve this aim in D, is one-class-per-file.

It's nonsense to suggest that this is nonsense. It's just fact.

I do not see why their would be such a strong objection to giving the programmer an alternative approach. That seems 'ideological' to me.

On Friday, 3 June 2022 at 22:50:06 UTC, forkit wrote:
> The aim of class abstraction is to support encapsulation and local reasoning. The best way to achieve this aim in D, is one-class-per-file.
>
> It's nonsense to suggest that this is nonsense. It's just fact.

your code must be enterprise-grade https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

On Friday, 3 June 2022 at 23:30:58 UTC, Steven Schveighoffer wrote:
> On 6/3/22 6:50 PM, forkit wrote:
>> On Friday, 3 June 2022 at 15:41:04 UTC, Mike Parker wrote:
>>> 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.
>> 
>> How is it nonsense? I don't get it.
>
> I think he means the "no exceptions" is nonsense. There are valid reasons to want to access private data from outside types.
>
> -Steve

First, this is not something I've argued against. I'm made no such argument that attempts to invalidate that point of view.

But his comment is very selective then, if that's what he meant, because my comments have been within the context of wanting static, compiler enforced, safety of the class. Which can only be done by putting every class in its own file. No exceptions.


I'm arguing to give the programmer another option, not take an option way.

On Saturday, 4 June 2022 at 00:41:24 UTC, forkit wrote:
>

I'd like it, if I had 'the option', to do something like this in D:

(where the attribute @sealed, results in static, compiler enforced, protection of the interface of that class, from any code outside of that class (i.e. code in the same module).

@sealed
@final
@orWhatever... it's irrelevant at this stage as to what the attribute could be called.


// --- some module file

@sealed class A
{

}


@sealed class B
{

}

// ------------

On Friday, 3 June 2022 at 22:50:06 UTC, forkit wrote:
> On Friday, 3 June 2022 at 15:41:04 UTC, Mike Parker wrote:
>> 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.
>
> How is it nonsense? I don't get it.

"anyone that uses a class in D...no exceptions"

Change that to "anyone who wants class-level encapsulation" and remove the "no exceptions" and it's sensible.

>
> I do not see why their would be such a strong objection to giving the programmer an alternative approach. That seems 'ideological' to me.

It would require adding a new protection keyword to the language. The general policy for that is that there must be a strong benefit. Given that we already have a way to achieve the same goal (putting classes in their own modules), then the benefit of such a keyword is extremely weak.

On Saturday, 4 June 2022 at 01:41:52 UTC, Mike Parker wrote:
>
> ....
> It would require adding a new protection keyword to the language. The general policy for that is that there must be a strong benefit. Given that we already have a way to achieve the same goal (putting classes in their own modules), then the benefit of such a keyword is extremely weak.

Well, I've never encounted as much resistance to change, as what occurs when someone brings this topic up in a discussion.

I really do think there is idealogical resistance to such a change, and it's this that brings about these strong reactions.

Cause D has plenty of completely useless attributes. I don't think another one is going to make much difference.

In the meantime, if a D programmer wants static, compile time verification that that the encapsulation of a class is not broken, then they MUST put that class in a separate module (one module per class).

No exceptions.

On Saturday, 4 June 2022 at 05:07:10 UTC, forkit wrote:
> On Saturday, 4 June 2022 at 01:41:52 UTC, Mike Parker wrote:
>>
>> ....
>> It would require adding a new protection keyword to the language. The general policy for that is that there must be a strong benefit. Given that we already have a way to achieve the same goal (putting classes in their own modules), then the benefit of such a keyword is extremely weak.
>
> Well, I've never encounted as much resistance to change, as what occurs when someone brings this topic up in a discussion.
>

I'm just expressing my thoughts on the topic. I think it would be a pointless addition to the language. But if you feel strongly enough about it, submit a DIP and see how it goes. I'm fairly confident it will be rejected since we already have a solution, but I could be wrong. A DIP that's persuasive enough to convince Walter and Atila is all you need.

On Saturday, 4 June 2022 at 05:13:25 UTC, Mike Parker wrote:
>
> I'm just expressing my thoughts on the topic. I think it would be a pointless addition to the language. But if you feel strongly enough about it, submit a DIP and see how it goes. I'm fairly confident it will be rejected since we already have a solution, but I could be wrong. A DIP that's persuasive enough to convince Walter and Atila is all you need.

But a DIP is the one sure way, of it never, ever...ever.. happening.

So I'm not surprised at your suggestion, to DIP it ;-)