On Wed, 18 Apr 2012 22:34:23 +0200, Stas Malyshev <smalys...@sugarcrm.com>
wrote:
Hi!
This would cause a lot of problems. Basically, all the functions that
rely
on ZEND_NUM_ARGS() will have to be changed. You can't tell if a
parameter
was passed or not by relying on it.
ZEND_NUM_ARGS() would probably work since IIRC it relies on stack size,
not on varargs return.
Not sure what you mean here. What is this "varargs return"? As far as I
see, a NULL pointer is pushed to the stack and ZEND_NUM_ARGS() will return
the size of the stack; in this case, the index of the last argument, not
the number of arguments actually passed. But even if it returned the
number of arguments passed, it would be irrelevant because you would not
know *which* arguments were passed.
Yes, that means ZEND_NUM_ARGS() and varargs would
return different things, and that means when you manually fetch args
from stack you'd have to check for NULLs - but these cases should be
quite rare and can be handled on case-by-case basis. Most functions
don't - and shouldn't - use manual stack parsing, and for those
everything would work just fine.
This is a straw man argument as I was not addressing manual stack parsing,
but, in any case, I think it reveals even a stronger argument against this
addition. There is no reason to think functions shouldn't do manual
argument parsing. In fact, they do, and there are even many ways to have
them do it -- zpp with Z*/z*/Z+/z+, _zend_get_parameters_array,
zend_get_parameters_ex and more. These are not one or two and they will
stop working,
But to my argument: many functions use ZEND_NUM_ARGS() to determine if an
argument was passed. Sometimes, this is the only way to determine if an
argument was passed -- for instance, if we're using zpp with "l", see
mt_srand() for an example. For a more drastic example, see the
implementation of PDOStatement::fetchAll().
Now, you may argue that this is a bad practice because you can't pass an
argument with a value with same effect of not passing it, and I would
agree. In fact, I've just gone through a great deal of trouble to avoid
having internal functions with this kind of behavior. See
https://github.com/cataphract/php-src/blob/intl_calendar/ext/intl/calendar/calendar_methods.cpp#L399
-- and guess what -- your feature would break this.
Good or bad, usage of ZEND_NUM_ARGS() is all over the place:
glopes@nebm:~/php/php-src$ git grep -n ZEND_NUM_ARGS | grep -v zend_parse
| grep -v zend_get_parameters | wc -l
364
(I removed its usage in zpp and similar)
the strong presumption that exists against new syntax changes. Maybe I'm
lucky, but the problem you're trying to solve is at most an occasional
minor nuisance for me. Plus, this solution encourages bad behavior. If
we
Please look at the RFC, it has links to multiple requests from users for
this feature.
I don't think this is a strong argument, I could find a number of
proponents for every crazy feature.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
