Re: [PHP4BETA] zend_fetch_resource_ex/ZEND_FETCH_RESOURCE & friends.

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 ... 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...) > You may indeed have a point that it may be a good idea to return the actual > resource id that was fetched. that could be one - but see above why i like a high-lvel thingie better... > > > >btw: i'm not very happy with this kind of low-level functions printing > >warnings at all. i think zend_fetch_resource_ex should just return NULL > >and maybe let ZEND_VERIFY_RESOURCE print a warning - at the module authors > >choice. > > Information is lost after fetch_resource returns. The quick and clean way > is to generate the warning when the most accurate information is known - > it's consistent with the way we do things all around Zend (and IMO is the > right way to do it). than lets have negative error-code (like unix does) and have ZEND_VERIFY_RESOURCE get the result. > > >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... tc PS: i'm still banging my head for a better implode.. > > Zeev > -- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > For a PGP public key, finger bourbon@netvision.net.il > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany