One thing that I'm personally don't really understand, is what kind of support this needs from the infrastructure. As far as I can tell, we could define php_database_interface (example), with the necessary callbacks, and use it directly in all pieces of code that require/support it.
I don't exactly see how this de-coupling through interfaces buys us anything, because in order to actually make any use of code of a given interface, you're going to have to use this interface directly. More accurately, we already do get de-coupling by using the php_database_interface struct (which can be implemented differently for every database module), and again, as far as I can tell, this is all we need. What am I missing? Zeev At 21:30 21/04/2002, Wez Furlong wrote: >$xmldoc = domxml_new_xmldoc(); >// populate nodes of document here > >// Now render it using whatever XSLT backend is available >$proc = xslt_create(); >$data = xslt_process($proc, $xmldoc, $xsl); > >The advantage is that the xml doc just created in code using >one extension can be dropped straight into the XSLT processor, >of a different extension saving line(s) of PHP script (which >converts the XML doc tree into text), and most likely (depending >on the internal implementation) eliminates that text >conversion and re-parsing before the XSLT processor can use it. >So thats less code to write, less for the ZE to parse/compile >and most likely it will be faster to execute than the equivalent >code in PHP script. > >It doesn't look like much, but it's the kind of thing that makes >PHP "really nice" to use. The same concept could be applied to >other extensions that are related in their application; for instance, >the vpopmail, imap and mailparse extensions could be used interchangably >for some purposes, image extensions could re-use each others image >handles and so on. > >All this can be done in user-space, but with a load of "glue scripts": >while we keep saying "but PEAR can do that", not all projects can or >want to use PEAR (sorry Stig!), in particular, some commercial projects >would prefer to keep things very lean, or would feel safer building >up their own frameworks. Having this kind of "native shortcut" is >an attractive feature, IMHO. > >Stig can probably come up with some better examples :-) > >--Wez. > > >On 21/04/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote: > > Hey, > > > > Although this sounds interesting I still have a hard time seeing the end > > result. > > Can you please give a description/examples on how this will impact the end > > user? > > > > Thanks, > > Andi > > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
