On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:
>Actually, data hiding is at the core of using objects, and objects are at the core of doing OOP.
Let's look at Stroustrup's definition:
Object-oriented programming is programming using inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction.
Data hiding is orthogonal to OOP. It can be used without inheritance, on struct members. Inheritance can be used without it.
>It should not come as a surprise, given C++, C#, Java, Swift, Javascript.. .. ... that a programmer might want to have more explicit access control... since they have it in those languages ... and those languages represent the vast majority of the worlds programmers.
It's the old way, the first attempt. A mistake. Modern programming languages tend to implement it differently, or even reject.
For example, in Google's Dart it was explicitly rejected:
https://github.com/dart-lang/sdk/issues/33383
It's not the first time this has been requested, but we have no current plan to add such keywords.
There is a reason Dart does not use class based privacy.
Dart allows dynamic invocations. If you write dynamic x = someObject(); x.foo; then the foo access does not know the class of the object in x. It must work independently of that.
Now, if x has a class with a private foo, should that function then be found? That depends on whether the access x.foo is inside that class. If it's protected, then it depends on whether the access is inside a subclass of the declaring class. That adds a lot of overhead to dynamic accesses. It's not impossible, but it's just not something that the Dart language is well suited for.
The library based privacy that Dart has is allows us to syntactically detect private member accesses, and use renaming per library to allow a more efficient implementation of dynamic access.
If we ever add some other sort of privacy, it's more likely to be instance based than class based. That means that you can only access such members through this or super, which ensures that we always know the type of the receiver and we avoid dynamic accesses.
> What is surprising, is the level of objection in the D community to allow such an option in D.
No offense, but it looks like your surprise comes from your inexperience.