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.
And what if the xxx resource also supports other interfaces? How do
extensions yyy (or zzz for that matter) know how to get a hold of the
actual interface method table? What if they are built later on as SCE?
What if yyy also exports a resource that could be used in xxx and zzz?
How do xxx and zzz know that?
Prior to streams, we had a lot of code doing this:
what = zend_fetch_resource(..., &type, 2, php_le_file(), php_le_socket)
if (type == php_le_file()) {
fp = (FILE*)what;
} else {
fd = (int)what;
}
While it's not the prettiest code (especially when it's repeated every
where), it got the job done by:
1) Knowing exactly which resource lists supported the interfaces it
intended to use (at compile/link time).
2) Knowing the implementation details of those resources
The interface API that I proposed adds a thin layer that makes it possible
to do this stuff dynamically. The way it works is by registering which list
entries that support interfaces.
Resources of that type must then be wrapped with a small structure that can
be queried to find the interface implementation(s) that are required.
The code snippet from above would end up looking something like this:
zval *resval;
zend_parse_parameters(... "r", ... &resval ... );
what = zend_list_find(Z_RESVAL_P(resval), &type);
if (php_iface_list_type_is_registered(type)) {
// We know that what is a php_iface_instance *
// Even though we had no prior knowledge of what the actual
// list entry is or how it is implemented.
php_database_interface *db;
if (PHP_IFACE_HAS(what, PHP_DATABASE_INTERFACE_ID, &db)) {
// Use the database methods
db->query(what, "select foo from bar");
}
}
> 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?
Just that it needs to be dynamic, and needs to be able to handle more than
just a single interface implementation.
But aside from that, it is basically doing what you describe; that's the
beauty of it: it's really quite simple and there is virtually no coding
overhead (if you compare it to the old issock stuff we were doing prior
to streams it's actually less code overall).
--Wez.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
