On Monday, 13 June 2022 at 17:08:55 UTC, Ali Çehreli wrote:
>
> ...
> I was surprised too. Then I realized D's view was better that C++'s (my frame of reference at the time). Then I realized I've been under the influence of C++'s view of OOP. Then I thought more about what encapsulation actually means. Then I realized encapsulation has nothing to do with access control. I am much happier with this repaired frame of reference.
>

Really? Sure, you can separate interface from implementation, without access control.

But you can also ensure you don't put signed int, into unsigned int - by 'just not doing it'.

It's the 'just don't do it' approach that bothers me.

The 'just don't do it' philosophy, of D, s not a good tool to rely on, in software design and development, especially at scale.

That is where 'private(scope)' comes in handy.

If I 'do' do it, or someone else 'does it', then the compiler will know that what I'm doing, or someone else is doing, conflicts with the intent as specified in the class.

It provides an level of assurance, that you simply cannot get without it.

That's its benefit.

There is no downside.

You always have the choice to use it or not - that should always be up to you to decide.

The problem with D, is that it decides this for you, and leaves you with only to options:

(1) just don't do it.
(2) put the class in its own file

To me, this is uncessarily restrictive, and puts an immediate constraint on me, before I've even begun to consider what design is best for me.



> > And the
> > 'friend' story rarely impresses them. The reply is always:
> "Ok, 'friend'
> > breaks OOP principles. Is D better because it breaks OOP in
> its own way?"
>

The 'friend' argument is a strawman.

No D programmer would need to alter anything they currently do, with the 'option' that I'm asking for.

But a large number of programmers coming to D, will have to change what they're currently doing - cause they have no option.


>
> I find D's 'private' very useful and I doubt a single project had any problem with it.
>
> Ali

this is another strawman.

the problem is not the d module, it's not having a choice.

On Monday, 13 June 2022 at 17:08:55 UTC, Ali Çehreli wrote:
>

also, it should be considered as an 'design' control, not an 'access' control.

you cannot prevent 'access' by simply saying it's private.

but a 'design' control that's not enforceable, seems pretty pointeless.

private(scope) -> would provide the D programmer with an optional, enforcable, design control.

Please explain the downside to this.

On Monday, 13 June 2022 at 17:08:55 UTC, Ali Çehreli wrote:
>
> ...
> Then I thought more about what encapsulation actually means. Then I realized encapsulation has nothing to do with access control. I am much happier with this repaired frame of reference.

But this has always been the case ;-)

Encapsulation is an abstract concept.

A cell can be considered encapsulated.
The earth could be considered enscapsulated.
The solar system could be considered encapsulated.
The galaxy could be considered encapsulated.
There is even some suggestions that the universe could be considered encapsulated.

whereas:

private(scope), is a real, compile-time-enforcable, design constraint.

On Tuesday, 14 June 2022 at 00:54:34 UTC, forkit wrote:
>
> It's the 'just don't do it' approach that bothers me.
>
> The 'just don't do it' philosophy, of D, s not a good tool to rely on, in software design and development, especially at scale.
>

I completely agree with this. It bothers me A LOT that it's the view of most people around here.

Why stop there? Why not remove any constraints in the language? After all you can just stop making mistakes. "Just don't do it."

Why do we need @safe, dip1000 etc.? Just verify the memory yourself, if you accidentally screw up then that's your fault, surely it isn't the language's fault.

@nogc? Nah we don't need that, just don't allocate using the GC.

On Tuesday, 14 June 2022 at 00:54:34 UTC, forkit wrote:
>
>> > And the
>> > 'friend' story rarely impresses them. The reply is always:
>> "Ok, 'friend'
>> > breaks OOP principles. Is D better because it breaks OOP in
>> its own way?"
>>
>
> The 'friend' argument is a strawman.
>
> No D programmer would need to alter anything they currently do, with the 'option' that I'm asking for.
>
> But a large number of programmers coming to D, will have to change what they're currently doing - cause they have no option.
>
>
>>
>> I find D's 'private' very useful and I doubt a single project had any problem with it.
>>
>> Ali
>
> this is another strawman.
>
> the problem is not the d module, it's not having a choice.

People also completely misunderstand what we're asking for.

We're not saying the current design is bad, I like module private as much as the next person, BUT I would really like to have the option to have a stricter private for classes whenever chosen.

I'd rather have a module with couple of classes that are somewhat closely related, than many files with classes.

It's honestly easier to maintain a small amount of files, than many files. You end up with so many tabs in your editor too, where as a symbol list is much easier to skip to the necessary class.

I really don't understand why people are so much against it when it can be added without interfering with existing code, but it surely will help.

Especially when you have projects multiple people work on, then it will help ensuring that someone in the future isn't gonna abuse it.