I think interfaces are a great API, not just for creating specific interfaces between specific extensions, but to let any "reusable" extension define a C interface. With this API, we can solve interface versioning problems at runtime too (instead of hacking around with cpp macros and such in the source).
Database extensions could use this to provide a common C-level interface to other extensions (such as for example a database abstraction layer). With interfaces to database extensions you can do stuff like binding a stream to a blob field in an insert (PEAR DB implements this in user space today). Also, interfaces could be used to implement a common type system. It would be great to be able to retrieve data from a database and feed the "datetime" type output directly to an xmlrpc extension and have it serialized correctly. Or let an extension define a form template (not in the interfaces template sense) that provide the same functionality between HTML form data and a database (this field is a datetime, please present it as such...). As for XML examples, interfaces could be used to provide SAX/DOM/XSLT interfaces to other extensions. Basically, we could say that only ext/xml needs to implement an SAX parser, and only ext/domxml needs to implement a DOM parser, other extensions such as ext/wddx should only use this interface. With this scheme we no longer have to expose bundled libraries to other extensions, which rids us of hellish configure problems like we just had with iconv. - Stig On Sat, 2002-04-20 at 23:39, Wez Furlong wrote: > Following on from my RFC about an interface mechanism, what we really > need is some brainstorming on what interfaces we need or would like to > have in PHP. I'm aiming at PHP 5. > > The following concepts have already been mentioned either by myself or > others as being something we'd like to see in PHP: > > DOM XML nodes/documents ---> XSLT processor. > Image Handle --> PDF, SWF or some other extension with image > embedding/processing. > Socket / Network "behaviours" for streams. > Memory Buffer accessors for streams (direct access to memory streams > buffers, or access to file contents via mmap or some other mechanism). > > What we need is to have the specifics worked out; the last few items are > relatively easy, but for something like XML we need to think about > sticking to a common subset of features that we can rely on, and > therefore a common set of methods that we would need in our interfaces. > Perhaps we might need 2 or 3 (or more) interfaces to properly deal with > XML based resources. > > If you have any other ideas where an interface would be useful, even if > you think it sounds silly, post it here. If you've ever thought "it > would be great if I could use an XXX resource in the YYY extension > functions", then we could implement that behaviour using interfaces. > > Remember, these interfaces are intended to be used in the C extension > code, not for PHP scripts, so please don't get them confused! > I know that some of this functionality can be handled in user-space by > using some kind of wrapper scripts or libraries, but it would be > extremely useful for PHP to do some of these nice things without relying > on glue scripts. > > Why am I making so much noise about this? A couple of recent threads, > despite degenerating into madness, have raised a few good points about > how PHP could evolve to become even better than it is now. > I see the interface idea as one method for this kind of improvement. > > --Wez. > > > -- > 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
