RE: [PHP-DEV] zend_parse_parameters

Andi Gutmans [mailto:andi@zend.com] wrote: > >Seriously though - if you put comments in big enough letters in > the header > >and source files, and any docs that use them, stating that they are > >much slower than the usual way of doing then we should have it covered? > > People don't read the .h files usually and copy from other extensions. We could name the function zend_VERY_SLOW_DO_NOT_USE_parse_parameters_hash() ;-) I understand your point though. > >While I understand your concerns about the performance of PHP as a whole, > >surely the performance of an extension is the concern of the extension > >author, and perhaps they should be the one to decide if they use a fast > >or a slow method of writing their code. If someone misuses the API for > >code in the PHP CVS repository then I'm sure that the people here won't > >waste any time in jumping on the naughty author and revert the commit ;-) > > It is not only the concern of the extension author. There are many people > on php-dev which monitor extensions for conventions & performance. In the > end, many people are using these extensions and the PHP dev team has a > responsibility for quality and performance. Leaving this up solely to the > extension author is wrong. That is more or less what I said, or what I meant to say, when I mentioned people jumping in and reverting. > Anyway, performance aside, there is also the point of conventions. Up to > now, PHP has been pretty much a functional language with an > argument list. A convention that I like! I don't really like the idea of so many args, but the alternative is to expose the openssl API and do everything manually; there will be less args per function but then there would be about 20 PHP_FUNCTION calls and a bunch of resource zvals. Not too nice :-) > IMO, it should be in very specific cases where it is clearly > beneficial to use arrays than passing 10 arguments. The guidelines should > also take performance into account and should only allow its usage in > functions where performance is not much of an issue. [...] > If we make it very clear it will be easy for PHP dev to shout > "Hey, you're > not allowed to use this in function foo() because of a, b, c". I agree. --Wez.