| Quirky Abstractions |
[Jun. 10th, 2010|03:18 pm]
|
Joel Spolsky had written an essay titled
"The
Law of Leaky Abstractions" where he discusses the fact that sometimes
one needs to be aware of details of the abstraction's implementation to know
how to properly make use of it. Today, I'd like to talk about an analogous
phenomenon which I came to call a "quirky" abstraction, in which
an abstraction over several technologies (probably two or more) fails to
expose certain features in one of the technologies that it abstracts.
I first noticed this concept in
a
Stack Overflow question of how to encrypt/decrtypt an SQLite database from
within Qt. Now, the Qt SQLite backend module links against the vanilla
SQLite and not its encrypted implementations, so in order to make use of them
one will have to recompile Qt and possibly expose some extra functionality in
the abstraction.
At the moment, I've also volunteered to help maintain
the Graph-Easy
CPAN module and the reason was that one of the features of GraphViz was
not exposed in its Graph-Easy backend, which brought the need to hack
something as a workaround.
Can quirky abstractions be avoided? I don't know. As the abstraced
technologies progress and gain more features, the abstraction
needs to keep up with them, which makes a situation of a quirky abstraction
more likely to occur.
I'm not sure quirky abstractions are as bad as leaky abstractions, but it's
still an phenomenon that we need to be aware of.
|
|
|
| Comments: |
From: (Anonymous)
2010-06-10 04:27 pm (UTC)
Interfaces | (Link)
|
The fundamental question here is what the abstraction really buys the user. What is the Qt SQLite backend module, how using it is simpler than just using SQLite directly in your code Qt based code? I cannot really comment on that one - but I've seen that frequently in the CPAN land that people create interfaces to use some module in some other module - and often the only value of these interfaces is the documentation and tests of example usage of those two modules together. If you use Catalyst::View::Email and it does not expose some functionality of Email::Sender::Simple then you are out of lack, but if Catalyst::View::Email was just an example of how to use Email::Sender::Simple from inside Catalyst you could easily modify it to suit your needs. Of course Catalyst::View::Email does do some additional work so it is a trade-off. | |
