3 ms·
It's an interesting article but the term 'Leaky abstractions' is not suitable here. This abstraction is not leaky at all. It sounds like a great abstraction in
by cryptica 5y ago
It's an interesting article but the term 'Leaky abstractions' is not suitable here. This abstraction is not leaky at all. It sounds like a great abstraction in fact. It's just the implementation that's slow and it's not because of the abstraction. The author himself admits "it’s relatively easy to think of ways to dramatically improve the performance of this scenario".
That fact that the issue can be easily resolved without changing the abstraction (the plugin system) is proof that the abstraction is not leaky.
A leaky abstraction would leak implementation details from the plugin to the caller and thus make it impossible to replace or modify the plugin without modifying the caller's logic. It doesn't appear to be the case here. It seems like the issue can be resolved just by changing the plugin's logic; the caller's logic would stay the same. This sounds like an excellent abstraction and could be the reason why the core logic hasn't had to be changed in 1998... It should be hailed as an achievement, not shunned as 'leaky'.
- ericlaw 5y agoThe abstraction leaks because the performance characteristics are inherently impossible to mask from the higher layers. There are other places where the abstraction leaks as well (try to add a file with a Unicode name to a Compressed Folder). It's true that you could add more and more code to try to make the abstraction leak less.
- cryptica 5y agoIt's not impossible because the author of the article themselves admit that there are many ways to fix this. I can already think of one possible way they could speed up the copy-paste from the zip file; by waiting until all files have been copied to the file system before deleting files from the zip in one go. The fact that solutions do not require a change to the interface is a sign that this is not a problem with the abstraction. Is it the abstraction which is forcing the files to be copied 1 byte at a time? It doesn't seem like it. It's an implementation issue. The interface allowed the plugin to have been implemented in many other ways, the implementer of the plugin just happened to go about it the wrong way.