Re: RFI: Request for Interfaces
| From: | Zeev Suraski | Date: | Tue, 07 May 2002 13:20:04 +0000 |
| Subject: | Re: RFI: Request for Interfaces | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-83786@lists.php.net to get a copy of this message | ||
At 12:12 07/05/2002, Wez Furlong wrote:
On 04/05/02, "Zeev Suraski" <zeev@zend.com> 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