Shlomif's Technical Posts Community - Quirky Abstractions [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

Quirky Abstractions [Jun. 10th, 2010|03:18 pm]
Previous Entry Share Next Entry

shlomif_tech

[shlomif]
[Tags|, , , , ]
[Current Location |Home]
[Current Music |The Beautiful South - Perfect Ten]

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.

LinkReply

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.