Hello Dmitry, just as you i was asonished by the fact that we don't have anything to convert an array to parameters. And for the fact of not blowing up zend api i decided to reduce the number of additional functions to a minumum. That way i came to the three ones i added. Now since i am using the first one for the 'f' parsing i added all of the three into the engine. I also find it just natural that stuff that is so tightly connected to a special structure should be located right next to that structures definition.
Also i wonder what makes you think the stuff is only usefull to iterators? The only thing that is useful only for iterators is the stuff added to SPL. So yes i didn't overblow the api by keeping iterator stuff in SPL. And last but not least you asked for an example that is what you got. Other places where we can use those three new api functions are PDO, SQLite, DOM and even other stuff in SPL as well as maybe all the array callbacks. Apart from that i haven't looked where else the stuff is useful. All i can tell is that we have a bunch of places that right now do not handle callbacks correct, meaning those parts don't support the full range of callbacks. Nonetheless your idea of zend_create_parameters_array() makes sense to me. Because your idea brings more flexibility than what we can do right now. That is we mostly use zend_get_parameters_array_ex() and have other helpers step in from there. But that only allows to pass all given parameters and not take them from a single array parameter as we do in several places. For instance have a look at pdo/pdo_stmt.c and there in function do_fetch_class_prepare(). That stuff can directly switch to use the new handlers. best regards marcus Monday, June 5, 2006, 9:57:27 AM, you wrote: > Hi Marcus, > SPL code with this patch looks great, but ZE overloaded with helpers those > are useful only for iterators. > I wondered that ZE hasn't any helper for IS_ARRAY to arguments array > conversion (may be I missed it). > I suggest reimplement zend_fcall_info_args() into > zval *** zend_create_parameters_array(zval *args); > and remove zend_fcall_info_call() > Thanks. Dmitry. >> -----Original Message----- >> From: Marcus Boerger [mailto:[EMAIL PROTECTED] >> Sent: Sunday, June 04, 2006 4:14 PM >> To: Dmitry Stogov >> Cc: internals@lists.php.net; [EMAIL PROTECTED]; 'Andi Gutmans'; >> 'Zeev Suraski' >> Subject: Re: MFHing zend_fcall_info_*() to 5.2 >> >> >> Hello Dmitry, >> >> the 'f' requires at least the first helper, so it makes >> sense to have all three of them in the engine. Attached you >> will find the patch for the helpers and the 'f' thingie for >> 5.2 and an additional patch for SPL to introduce >> iterator_apply() which uses the stuff. >> >> marcus >> >> Wednesday, May 31, 2006, 12:46:59 PM, you wrote: >> >> > Hmm, >> >> > Seems 'f' really make sense for simplification. >> > I am not sure about other helpers. >> > I'll need to review patch once again. >> > Could you include some use-cases (SPL patch that uses this one)? >> >> > Thanks. Dmitry. >> >> >> -----Original Message----- >> >> From: Marcus Boerger [mailto:[EMAIL PROTECTED] >> >> Sent: Wednesday, May 31, 2006 12:19 PM >> >> To: Dmitry Stogov; internals@lists.php.net >> >> Cc: [EMAIL PROTECTED]; 'Andi Gutmans'; Zeev Suraski >> >> Subject: Re: MFHing zend_fcall_info_*() to 5.2 >> >> >> >> >> >> Hello Dmitry, >> >> >> >> my patch doesn't change anything. If just adds stuff that >> >> deals with defined functions only. If now you want to support >> >> all functions that can be defined later it wouldn't work this >> >> way (1). Actually it would require parsing the zval and >> >> checking whether it might get callable in some future. While >> >> this is the right solution for error handlers it is not the >> >> right way for stuff like callback in array and SPL functions. >> >> Once those are called the callback is used hence there is no >> >> way it can suddenly come out of nowhere. My patch now >> >> adresses this in a way that is much more efficient than doing >> >> a two phase approach. >> >> >> >> best regards >> >> marcus >> >> >> >> (1) I experiemened with 'F' parsing that only verified if >> >> something might get callable at some point. Though that >> >> worked it was unneccessary slow for the intended purpose. >> >> >> >> Wednesday, May 31, 2006, 8:29:01 AM, you wrote: >> >> >> >> > Hi Marcus, >> >> >> >> > We discussed the patch. >> >> >> >> > Several notes: >> >> > PHP allowed pass callback function or method that is not >> >> defined yet. >> >> > Your patch disallows this. >> >> >> >> > <?php >> >> > some_internal_func("foo"); >> >> > eval("function foo() {}"); >> >> ?>> >> >> >> >> > Usage of default values for functions will be problematic >> >> with it. I >> >> > don't think that we really need special case for 'callback' >> >> afguments. >> >> > (It would be good for strong-typed language). >> >> >> >> > According to helpers, I would like suggest to add them into SPL >> >> > itself and don't overload ZE. >> >> >> >> I can do so but don't see sense in doing so. >> >> >> >> best regards >> >> marcus >> >> >> >> >> >Date: Sat, 27 May 2006 22:32:13 +0200 >> >> >> >From: Marcus Boerger <[EMAIL PROTECTED]> >> >> >> >Reply-To: Marcus Boerger <[EMAIL PROTECTED]> >> >> >> >To: Andi Gutmans <[EMAIL PROTECTED]>, Zeev Suraski <[EMAIL >> >> >> >PROTECTED]>, >> >> >> > Ilia Alshanetsky <[EMAIL PROTECTED]> >> >> >> >Cc: internals@lists.php.net >> >> >> >Subject: MFHing zend_fcall_info_*() to 5.2 >> >> >> >X-Bogosity: No, tests=bogofilter, spamicity=0.000475, >> >> version=0.92.8 >> >> >> > >> >> >> >Hello Andi, Zeev, Ilia, >> >> >> > >> >> >> > the attached patch adds three new functions that >> make calling >> >> >> >functions a lot easier - at least for me in SPL. And it also >> >> >> does a few >> >> >> >things correct which are probably overseen easily. The >> >> >> addition works >> >> >> >in HEAD already and paases all memcheck tests idid so far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
