At 12:12 07/05/2002, Wez Furlong wrote: >On 04/05/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote: > > 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. > >Let's say extension xxx exports a resource to user-space that supports >php_database_interface. >How does extension yyy: >1) Know that the resource supports php_database_interface >2) Manage to do that without having compile/link-time knowledge of what > other extensions are present.
Ok, I understand the benefits. I think we should avoid introducing a new mechanism, and mainstream it on top of the existing resource mechanism, as integrated as possible: 1. You would have a basic rsrc_interface_base structures, which will only have one element - the interface type. 2. When you register a resource type, you'd be able to pass a pointer (or pointers) to a structure (or structures) that implement various interfaces. For instance, if you register a MySQL result set resource, you'd pass a pointer to mysql_sql_interface. This struct will also contain the interface_type element in its beginning, so you'd be able to cast it to rsrc_interface_base to know what type of interface it is (in this case, the entry will contain INTERFACE_SQL_RESULT_SET, for example). 3. Add a function that checks whether a certain resource id supports a certain interface, and returns the pointer to it, or NULL if it doesn't. How does that sound? Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
