On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell
wrote:
in D, once your write your abstraction, say a class, with it's
public interface, all the code below it can do whatever it
likes to that class, making it a leaky abstraction.
I think there might be some confusion between "leaky abstraction"
and "insufficient encapsulation".
Here's the Wikipedia definition of leaky abstractions:
"In software development, a leaky abstraction is an abstraction
that *requires* knowledge of an underlying complexity* to be able
to know how to use it. This is an issue, as the whole point of an
abstraction is to be able to abstract away these details from the
user. "
Why would imply that: as long as the user of your class isn't
*required* to know about the underlying implementation specifics,
this isn't a "leaky abstraction".
My understanding is that:
"Leaky abstractions" are about the interface design, and how one
component is meant to be used. Those are unrelated to the
programming language (e.g translating the code to another
language doesn't make the leaky abstraction disappear).
For example, a shared directory can be a leaky abstraction, if
the network is unstable (because then, the client code, which
only sees file descriptors, now has to deal with disappearing
files).
"Encapsulation" is about implementation hiding and access control
("public/private"), and requires programming language support
(e.g most dynamic languages don't have it).
