Re: RFI: Request for Interfaces

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" <andi@zend.com> 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