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
