Proposed Apocrypha
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap. Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second. --eaton
On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
--eaton
Choir sings: Amen, Brother Eaton.
On Thu, 7 May 2009 09:23:48 -0500 Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
If you want to make stuff swappable start at least with 3 implementations otherwise 2 will just be a special case of 1. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Thu, 7 May 2009 09:23:48 -0500 Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
If you want to make stuff swappable start at least with 3 implementations otherwise 2 will just be a special case of 1.
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs? And three cheers for Crell's Law and Eaton's Corollary. Cheers, Greg -- Greg Knaddison | 303-800-5623 | http://growingventuresolutions.com Cracking Drupal - Learn to protect your Drupal site from hackers Now available from Wiley http://crackingdrupal.com
On May 7, 2009, at 10:25 AM, Greg Knaddison wrote:
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs?
Also, the rules and corollaries I'm brainstorming are limited by the fact that I'm trying to fit them into Twitter-compatible 140-character snippets. It's a nice exercise in simplicity when explaining principles can easily veer into long digressions. ;-) I agree that three implementations is better, because we're more likely to run into REAL variations, but as you say it's not necessarily realistic that very new API have three fully fleshed out example implementations. We can work towards it, and encourage it, but it's the "only one implementation" scenario that should really set off warning lights when we see it. The "write two" is mostly about smoke- testing for 'fake APIs' that look like swappable subsystems but are still too anchored to the original implementation to be replaceable. Also, I don't think we necessarily HAVE to include each of our test implementations in core. But we should at least write them whenever possible, to flush out problems and also to reveal areas where 'perfect flexibility' isn't worth the overhead. (A persistence layer that can use SQL databases or XML files would be terribly flexible but probably not worth the work, for example.) -eaton
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs?
I don't think so. But we could say we won't release Drupal 7until at least one swappable backend is ported in contrib. To some extent this is the same thing as getting Drupal.org running on a beta/RC before release - at least for critical systems like caching. Nat
On Thu, May 7, 2009 at 11:25 AM, Greg Knaddison <greg.knaddison@gmail.com>wrote:
On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Thu, 7 May 2009 09:23:48 -0500 Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
If you want to make stuff swappable start at least with 3 implementations otherwise 2 will just be a special case of 1.
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs?
Moreover, The whole idea of making it swappable is to avoid hacking core (and killing kittens) yet be able to customize things in new ways, without being limited by core's strict process and patch cycle. Experimentation is much easier with swappables in contrib. "Never underestimate the power of contrib ..." -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
On Thu, 7 May 2009 09:25:53 -0600 Greg Knaddison <greg.knaddison@gmail.com> wrote:
On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Thu, 7 May 2009 09:23:48 -0500 Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
If you want to make stuff swappable start at least with 3 implementations otherwise 2 will just be a special case of 1.
We have to temper the ideal with reality. We have several
That`s why I didn`t write "working implementations" ;) At least in my experience a "what if they were 3" makes a huge difference to avoid 2 just a special case of 1. But anyway how could you plan or even think an API could be useful knowing just 2 use-case? But then... when you cut and paste more than once... you need an API ;) 3 is the magic number!
And three cheers for Crell's Law and Eaton's Corollary.
I would extend that cheers further than just for the Law and the Corollary. BTW Ernie that`s called delegation and everybody know that delegation is the solution to all CS problems. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote:
At least in my experience a "what if they were 3" makes a huge difference to avoid 2 just a special case of 1. But anyway how could you plan or even think an API could be useful knowing just 2 use-case? But then... when you cut and paste more than once... you need an API ;) 3 is the magic number!
3 is ideal. Two markedly different implementations can also suffice, for certain definitions of "markedly". (DBTNG was good with MySQL and Postgres, with an eye toward Oracle. It's better with SQLite, which forced some heavy rethinking that ended up making a much cleaner implementation without changing the API.)
And three cheers for Crell's Law and Eaton's Corollary.
I would extend that cheers further than just for the Law and the Corollary.
BTW Ernie that`s called delegation and everybody know that delegation is the solution to all CS problems.
There is no problem in computer science that cannot be solved by adding another layer of indirection (except micro-performance). --Larry Garfield
On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
--eaton
As I noted on IRC when this was mentioned, maybe there should be another law. Drupal Law 0: If you need to do something, make an API for it first. Or maybe that's just eaton's first law? ;)
That's dopry's first law... On Thu, May 7, 2009 at 12:40 PM, James Gilliland <neclimdul@gmail.com>wrote:
On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
--eaton
As I noted on IRC when this was mentioned, maybe there should be another law.
Drupal Law 0: If you need to do something, make an API for it first.
Or maybe that's just eaton's first law? ;)
Quoting James Gilliland <neclimdul@gmail.com>:
Drupal Law 0: If you need to do something, make an API for it first.
print t('Hello World'); Oh wait I should create an API to do it first. function print_hello_world() { print t('Hello World'); } print_hello_world(); Oh wait I should create an API to do it first. function execute_print_hello_world() { print_hello_world(); } execute_print_hello_world(); Oh wait I should create an API to do it first. ... Endless cycle. I think you need a better descriptor than ``something'' before you make an API. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
Quoting James Gilliland <neclimdul@gmail.com>:
Drupal Law 0: If you need to do something, make an API for it first.
print t('Hello World');
Oh wait I should create an API to do it first.
function print_hello_world() { print t('Hello World'); }
That's not an API, that's abstraction. Kind of. It doesn't follow any of the rules, which has to do with flexibility and reusability. So it's bad abstraction. :P
On Thu, May 7, 2009 at 2:54 PM, Earl Miles <merlin@logrus.com> wrote:
Earnie Boyd wrote:
Quoting James Gilliland <neclimdul@gmail.com>:
Drupal Law 0: If you need to do something, make an API for it first.
print t('Hello World');
Oh wait I should create an API to do it first.
function print_hello_world() { print t('Hello World'); }
That's not an API, that's abstraction. Kind of. It doesn't follow any of the rules, which has to do with flexibility and reusability. So it's bad abstraction. :P
I personally like designing at the interface level. It's so much neater... then you can start thinking about the hairy details of abstract and concrete classes and their guts. Admittedly the normal Drupal model is implement an API that provides and abstration to select the properly implementation of an API's beckend interface... Now if you had.... drupal_print_string("Hello World"); function drupal_print_string($string) { $function = variable_get('drupal_print_implementation', 'default') .'_print_string'; return $function($string); } function default_print_string($string) { print $string; } These day I prefer stuff more along the lines of .... intrerface iPrinter { bool print(string str); } class defaultPrinter implements iPrinter { function print($str) { print($str); } } class printerFactory { function load($implementation) { if (in_array('iPrinter', class_implements($implementation))) { return new $implementation(); } // maybe throw an exception.... } } $pf = new printerFactory(); $printer = $pf->load(variable_get('default_printer_implementation', 'defaultPrinter')); $printer->print('Hello World'); I feel its a little more work to set up the interface and factory, but it's so much easier to expand the implementations, especially when you only need to overload one or two methods...
participants (11)
-
Chris Johnson -
Darrel O'Pry -
Earl Miles -
Earnie Boyd -
Greg Knaddison -
Ivan Sergio Borgonovo -
James Gilliland -
Jeff Eaton -
Khalid Baheyeldin -
larry＠garfieldtech.com -
Nathaniel Catchpole