Wed Oct 17 - Avoiding Code Smells by Walter Bright

[Sebastien Alaiwan]

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).