Re: [PHP4BETA] zend_fetch_resource_ex/ZEND_FETCH_RESOURCE & friends.

At 16:14 23/09/1999 , Thies C. Arntzen wrote:

On Thu, 23 Sep 1999, Zeev Suraski wrote: At 08:56 23/09/1999 , Thies C. Arntzen wrote:

On Thu, 23 Sep 1999, Zeev Suraski wrote:

Hmm, you're not supposed to pass NULL as the resource_type_name.

than we need to have an _ex_ex() API call. some functions can take 2 different types of resources (see attached ora_error). either zend_fetch_resource_ex needs to "shut-up" or we need a new parameter that also returns the resource_type so that the caller can find out what kind of a resource he got back!

Well, we have a difference in opinion about what this function should do... I'm not sure how come you're fetching a resource type that cannot be grouped under a single name, but if you are, you shouldn't be using zend_fetch_resource_ex, but the low level functions. Looking at the Oracle code there, you can easily group the resource types under the word 'Oracle' or something like that, and 'foo is not an Oracle resource' is a descriptive enough a warning. that's not the solution - in this case we have two completly different types of resources (db-connection, db-result-cursors), the underlying structures are different aswell - as you can see from the code. ora_error will return the last-error for the connection if it's passed a connection, and the cursor code if ...

Ok, it's different enough from the rest of the stuff I've been involved with. I guess that adding in the NULL checks for 'only check if a resource exists but no biggy if it doesn't' makes sense.

i like to take a high-level approach as that would allow us to change the underlying mechanisms easy - if we ever want to - and it makes writing of modules easier the more functionality libzend offers! talking about high-level - the persistent connection stuff is a very good sample of code that's nearly impossible to unterstand (mysql_do_connect) if you don't understand *all* the libzend internals that play together (list, plist, le_index_ptr...)

True. One actually has to know how to code to write a persistent module :) We may add some abstraction as time goes by, but right now I support the 'if it ain't broke don't fix it' approach.

than lets have negative error-code (like unix does) and have ZEND_VERIFY_RESOURCE get the result.

I'm against this. People always tend to ignore return values from functions, and it'll also cause repetitive code. I really believe in the 'display the error as soon as you encounter it' approach, and I'm not looking for alternatives. Since you raised an issue where not finding a requested resource is something that is normal and shouldn't display an error message, the improvement to selectively turn this error off makes sense; But I still think the error should be built into the function code.

another thing that could be nicer is the ZEND_REGISTER_RESOURCE() - often a module needs to store the list-id somewhere for it's own purposes. right now you have to do (from php_mysql.c):

        ZEND_REGISTER_RESOURCE(return_value, mysql, le_link);

        /* add it to the hash */
        new_index_ptr.ptr = (void *) return_value->value.lval;

i think we should make ZEND_REGISTER_RESOURCE a function that returns the new id!

Sounds like a good idea - I'll look into it tonight. al least you like one of my ideas - i'm smiling...

I like many of your ideas :) Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il