On Mon, Jun 13, 2022 at 11:33:35AM +0000, Ozan Süel via Digitalmars-d wrote:
> It's the name of the language ;-)
> 
> Try to find "D". You will get a long list of results from everything and everyone.

Just search for "dlang" instead.


T

-- 
I see that you JS got Bach.

On 6/12/22 03:40, Max Samukha wrote:
> On Sunday, 12 June 2022 at 09:54:42 UTC, Ola Fosheim Grøstad wrote:
>
>>
>> Many OO languages don't provide encapsulation, like Python.
>
> Right, but Python programmers are expected to prepend private members
> with '_'.
>
>> I would say encapsulation has more to do with scaling up and evolving,
>> as well as reliability (e.g. actors).
>> But I guess you can say that OO features span a space where
>> encapsulation is one dimension.
>
> Then it is natural to expect the feature would apply to the class level
> (if we are talking about class-based OOP)? Really, I'm yet to meet a D
> user that wouldn't be surprised 'private' is module-level.

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.

> 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?"

Access control is just an aspect of OOP. Neither friend nor module-level private breaks OOP. Being a simpleton, I start reading from Wikipedia but others can read their trusted OOP gospel to gather the same information:

  https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

For example:

  "Under the definition that encapsulation "can be used to hide data members and member functions", the internal representation of an object is generally hidden from view outside of the object's definition."

Note "can be used to hide" and "generally hidden". See, all the other languages apply their view of 'private', not OOP's view of 'private'.

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

Ali

On 14/06/2022 5:08 AM, 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.

Replace C++ with Java and I'm the same.

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

Same.

I've got many more problems with export being a visibility modifier than private has ever given me.

On Monday, 13 June 2022 at 17:34:32 UTC, rikki cattermole wrote:

>
> I've got many more problems with export being a visibility modifier than private has ever given me.

I bet you would have even fewer problems if there weren't 'private' at all.

On 14/06/2022 7:04 AM, Max Samukha wrote:
> On Monday, 13 June 2022 at 17:34:32 UTC, rikki cattermole wrote:
>> I've got many more problems with export being a visibility modifier than private has ever given me.
> 
> I bet you would have even fewer problems if there weren't 'private' at all.

You can't go lower than zero.

Export on the other hand, blocks whole uses cases for D.

On Monday, 13 June 2022 at 19:13:56 UTC, rikki cattermole wrote:

> You can't go lower than zero.
>
> Export on the other hand, blocks whole uses cases for D.

True.

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

>
> Access control is just an aspect of OOP. Neither friend nor module-level private breaks OOP. Being a simpleton, I start reading from Wikipedia but others can read their trusted OOP gospel to gather the same information:
>
>   https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
>
> For example:
>
>   "Under the definition that encapsulation "can be used to hide data members and member functions", the internal representation of an object is generally hidden from view outside of the object's definition."
>
> Note "can be used to hide" and "generally hidden". See, all the other languages apply their view of 'private', not OOP's view of 'private'.
>
> I find D's 'private' very useful and I doubt a single project had any problem with it.
>
> Ali

I am not debating its usefulness, but it would be even more useful if it meant what I believe most programmers not damaged by Simula or Pascal intuitively expect, that is, 'private to the parent scope'. And then we could have something like 'private(ancestor)' (or extend 'package(ancestor')) for specifying the desired boundary of encapsulation.

Currently I just cannot enforce class invariants (without isolating the class in its own module). See this gospel:

"Encapsulation also protects the integrity of the component, by preventing users from setting the internal data of the component into an invalid or inconsistent state." (https://en.wikipedia.org/wiki/Information_hiding#Encapsulation)

On Monday, 13 June 2022 at 12:33:32 UTC, jmh530 wrote:
>
> A fair point, but one of the arguments (over who knows how many pages at this point...) is that some people want to be able to have some way to ensure that the only way to access internal members is controlled through the class itself. You would reply that there is an alternative, which is to put that class in a separate module. It is a little like @safe (in a project with no dependencies, is @safe useless because the programmer has access to all the code and can verify themselves whether there are any errors?). Some people want guarantees. The people arguing for this want the guarantee that if they write some other function *in the module* that tries to access one of this internal members, then they get an error. Now, that's not something that has been a concern to me, but I don't necessarily think it is a useless feature.

of course, this is primarly a matter of scale (both in terms of code, and people contributing to that code - even withint the same module, and not just now, but in the future as well).

the only way to scale in D when using OO designs, without this feature, is to put every class on it's own in it's own module - for no other reason than to protect the code of the class from any other code.

that is not scalable.

sure, some choose to put one class per file - that is a design decision - not one that should be forced on to you, by the language, because the language refuses to provide the tools you need.

you should be able to protect the code of your class, from surrounding code, without being told this is the only workaround we can provide for you.

there is no downside to having an option to contain private parts to the scope of a class. What a complete joke to suggest there is.

people will choose to use it , or not - but they'll have a choice.

of course I already have that choice, in ALL the languages I currently use - except for D. Every C++/C#/Swift/.../.. programmer can already do this.

There is a strong 'anti' class-private group in the D community.

There motivations are their own, and not all that clear to me.

But they sure are intent on ensuring i (and everyone else that uses D) don't have that choice.