Re: [RFC] skipping optional parameters

On Wed, 18 Apr 2012 22:34:23 +0200, Stas Malyshev <smalyshev@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