On Tuesday, 15 May 2018 at 12:20:34 UTC, aliak wrote:
On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
On Tuesday, May 15, 2018 04:22:30 Mike Parker via
Digitalmars-d wrote:
On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> - Object independence
> - Do not violate encapsulation
> - Respect the interface
This is what I don't get from your position. What is
encapsulation? Here's what Wikipedia says [1]:
[...]
The class in D *is* encapsulated. The interface *is*
respected. I'm not sure what you mean by object independence.
[1]
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
If you really insist on the viewpoint that class encapsulation
means that nothing outside of that class can access any of its
private members, then what D does definitely breaks
encapsulation. But having friends in C++ already provides a
way to break that. And having access levels like protected and
package break it. Ultimately, a good language provides ways to
encapsulate data and control access to the internals of a data
type, but there are a variety of ways that that can be
achieved, and I don't think that I've ever used a language
that strictly enforces that nothing can access the internals
of a class. It's just that each language provides different
ways for stuff outside the class to access the class'
internals.
D happens to have gone with a very liberal approach to
encapsulation by essentially making everything inside a module
friends of each other. It doesn't break the concept of
encapsulation any more than C++'s friend or Java's package
attribute do. It's just a much more liberal default, and if
you're really insistent that nothing outside of a class has
access to the stuff inside a class, then D's choice is likely
to be seem terrible. So, in that sense, I can see where he's
coming from, but ultimately, I think that it's a very narrow
viewpoint about what encapsulation means, and for most of us,
experience has shown that D's choice works extremely well in
practice.
Either way, as long as you understand how D works with
private, you have basically the same level of control as what
you get with C++ and friend. It's just that if you _really_
don't want anything else to be a friend, you're forced to
stick it in another module. So, ultimately, I think that it's
mostly a theoretical debate. Pretty much the worst that
happens is you accidentally use a member variable directly
instead of using a property function to access it, and that's
rarely a big deal. Often, it's even desirable.
[...]
- Jonathan M Davis
With one big difference, in that those other languages make you
explicitly leak object internals, if you want it, and also
allow you to maintain it, if you want it, whereas D implicitly
leaks class privates to the module whether you want it or not.
So private in a class is nonintuitive and does indeed break
encapsulation. This is why Swift has fileprivate to distinguish
this case, and for good reason.
So I understand D wants to be liberal, but I also understand
the value of "encapsulation where I want encapsulation to
happen", which D doesn't let me do without jumping through
extra hoops (extracting class to another module with the caveat
that you lose first-class UFCS enabled function access), and
only after I've spent hours trying to track a state-related bug
because private is not scoped at the declaration level.
Cheers
- Ali
The way you use the word "leak" make is sounds that this is
unintentional, while in reality it is intentional by design. That
why reading the specification is important!
Alexander
