On 07/05/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> 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:
Good!
> 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?
It sounds very close to what I originally proposed :-)
Harald made a reasonable request for being able to do something similar
for objects with a custom zend_class_entry. A simple way to achieve this
would be to add a field to zend_class_entry that contains the interface
type you talk about in (1.) above.
Would you like me to post my interface code here (or by private mail)?
There's not really much to it - 1/3 of it is comments:
% wc main/php_ifaces.h main/ifaces.c
130 728 6004 main/php_ifaces.h
200 521 5519 main/ifaces.c
330 1249 11523 total
I'd be quite happy to adapt it to integrate with the ZE according to your
suggestions.
--Wez.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
