On Saturday, 4 June 2022 at 05:07:10 UTC, forkit wrote:
> ...
> Cause D has plenty of completely useless attributes. I don't think another one is going to make much difference.
> ...

I have no opinion on the merit being discussed except this part, because I do think that keep adding more attributes will hurt D in a long term, in fact this is becoming a pattern in this language... there is a problem? -Let's add this attribute to solve.

If possible this should be thought in a way to be solved without adding new attributes.

Matheus.

On Saturday, 4 June 2022 at 05:20:58 UTC, matheus wrote:
> On Saturday, 4 June 2022 at 05:07:10 UTC, forkit wrote:
>> ...
>> Cause D has plenty of completely useless attributes. I don't think another one is going to make much difference.
>> ...
>
> I have no opinion on the merit being discussed except this part, because I do think that keep adding more attributes will hurt D in a long term, in fact this is becoming a pattern in this language... there is a problem? -Let's add this attribute to solve.
>
> If possible this should be thought in a way to be solved without adding new attributes.
>
> Matheus.

I don't agree.

The increased use of attributes is really the best way to accomodate change, rather than keywords or syntax changes.

D is more of a hobby language to me anyway, so I couldn't care less what it does. But to the extent it allows me to do things -> the way I want to do them, then and only then, does it maintain my interest.

On 6/3/22 22:07, 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 think the reason is there is no strong argument for one way or the other. There are two options:

a) 'private' means "private to the class", which necessitates the equivalent of the keyword 'friend'. This option is what C++ chose.

b) 'private' means "private to the module", which frees 'friend' as a user symbol. This option is what D chose.

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

Since D came after C++, it is clear that option b was seen to be superior. Let's hear arguments why option a is better than b.

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

It will make N+1.

> In the meantime, if a D programmer wants

Ah!

> static, compile time
> verification that that the encapsulation of a class

Ah!

> is not broken, then
> they MUST put that class in a separate module (one module per class).

Where did "wants" and "encapsulation of class" come from? Why would a D programmer not "need" "encapsulation of module"? Let's hear arguments about why one is better than the other. Which text book are we following?

Why are you stopping at class level? Why would one member function of a class access members that were supposed to be touched only by another member function? Where is that abstraction? Why don't we "want" that? Is it because other languages don't provide that? This whole discussion of encapsulation levels is arbitrary.

> No exceptions.

I am not going to contribute to your projects. Life is too short to follow "core guidelines". How about actually getting things done?

Ali

On Saturday, 4 June 2022 at 07:04:35 UTC, Ali Çehreli wrote:
>
> ...
> I think the reason is there is no strong argument for one way or the other. There are two options:
>
> a) 'private' means "private to the class", which necessitates the equivalent of the keyword 'friend'. This option is what C++ chose.
>
> b) 'private' means "private to the module", which frees 'friend' as a user symbol. This option is what D chose.
>
> > I really do think there is idealogical resistance to such a
> change, and
> > it's this that brings about these strong reactions.
>
> Since D came after C++, it is clear that option b was seen to be superior. Let's hear arguments why option a is better than b.

It's interesting that whenever this topic is brought up, that people in the D community (like you, for example), try to rephrase it as if we're all being forced to make a choice between A *or* B.

I'd like to have A *and* B.

You normally come up with ideas to issues that people raise (even ideas that to me see pretty ordinary), except, when it is this issue??

Why this idea encounters sooo.. much resistance, is..well. interesting.

The rest of your response I couldn't make any sense of.. so I'll ignore it.

In the end though, encapsulation of a class, in D, is broken, and cannot be statically verified by the compiler, unless you put that class in it's own file (which is what you're expected to do anyway, based on the reponses this idea always provoke).

Since there is no option B, to do otherwise, is what I would consider unsound programming, as it is not possible to reason about the code of the class contained within a module, without understanding ALL the code in that module.

It's also not possible to prove (again, without human intervention) that other code in the module does not violate the modular requirements of the class.

A possible counter agrument to the above, is that there is no encapsulation of a class in D. The module provides all the encapsulation anyone will ever need.

I'm not sure I'd want to be on that side of the argument ;-)

On Saturday, 4 June 2022 at 11:15:13 UTC, forkit wrote:
> In the end though, encapsulation of a class, in D, is broken, and cannot be statically verified by the compiler

Good OOP code accesses objects through interfaces anyway. The class itself ought only be used to construct it.

On Saturday, 4 June 2022 at 11:15:13 UTC, forkit wrote:

>
> Why this idea encounters sooo.. much resistance, is..well. interesting.
>

As I see it, this is a matter of "thinking in D" vs "thinking in something else". When you think in the language you're using, you organize your code to best take advantage of that language's features. D gives you the tools you need to have the strict encapsulation you want--classes can go in their own module; package modules present a single module interface to the world; package protection allows internal access within the package where necessary. What I don't understand is, what's so hard about that?

> In the end though, encapsulation of a class, in D, is broken,

Two things here.

1) There's a fundamental disagreement that encapsulation is broken. As I see it, it isn't broken. Any class I implement in a module is encapsulated from outside that module. I don't have any need for encapsulation inside the module, anymore than I would have any need for encapsulation inside the class (i.e., restricting access to a private member to a single member function). Since they're all in the same file, there's no difference whatsoever outside of a conceptual one. If you have access to the module's source, you have access to the private members.

2) A solution exists for anyone who cares about that conceptual difference. We don't need a new keyword/attribute to do something you can already do.


> A possible counter agrument to the above, is that there is no encapsulation of a class in D. The module provides all the encapsulation anyone will ever need.
>

I would almost say "Exactly!" to this, if not for the "all the encapsulation anyone will ever need". The module is the unit of encapsulation in D. But, as you demonstrate, some people just aren't comfortable with that. So they have the option to put their classes in separate modules.

On Saturday, 4 June 2022 at 12:28:41 UTC, Mike Parker wrote:
>
> 2) A solution exists for anyone who cares about that conceptual difference. We don't need a new keyword/attribute to do something you can already do.
>

Umm..no.

Once again, you're rephrasing my argument to suit you're agenda ( of sprouting the 'superior' approach of D).

If I could aready do what i want to do, I would not be discussing it.

I'd like the option to improve type soundness of a class, so that I can confidently have other code in the module, and thereby have the assurance that other code does not violate my class invariants.

I cannot currently do that in D.

It's a bit like having an invariant near the top of the module, that says x must not equal 0.

But 85 lines down in the code, someone has set x to 0.

An you're argument would be, hey, just put x in its own module then.