Hi! > Before addressing the points individually, I have to reiterate that > internal functions have no concept of default values. I think this
I disagree. Most of them certainly do, for example, look at strpos documentation: int strpos ( string $haystack , mixed $needle [, int $offset = 0 ] ) $offset is documented as having default of 0. Right now it is implemented in ad-hoc manner - i.e. you set up the value, but you don't actually declare it anywhere as some special "default value". But it is certainly there and for the user it is certainly a default as any other. We didn't do the best job documenting all these, unfortunately (see below) but in almost all cases they are there. > Instead, we have lots of functions that will not only break (see below for > a definition of "break"), but break subtly (e.g. uninitialized values) and Any function that passes uninitialized value to optional argument has a bug and needs to be fixed. > only under very particular conditions (using this new feature). Plus, they > increase the complexity of doing argument parsing (surely no one will > forget checking for NULLs). All the functions that use ZEND_NUM_ARGS() > have to be reviewed and the PHP core is just the tip of the iceberg. For 99.9% of the functions there's no increase of complexity since they already do the right thing. As for the matter of checking for NULL being too complex - this is the absolutely basic thing you always do in C, check your pointers, if you write engine code it can't be too complex for you. > I was talking about ZEND_NUM_ARGS(). My point is that ZEND_NUM_ARGS() now > gives near-0 useful information. Yes, you can know which arguments were > passed through other means, but not via ZEND_NUM_ARGS(), which what many > functions are currently using. This is not true. It gives the same information as before, and it is very useful. The only case where you'd have to take some extra case is where you do not use recommended APIs but try to fetch arguments from stack manually or when you have complex dependencies between parameters. Then you'd have to check for NULLs and decide if you are ready to accept parameters after that. Not rocket science by any measure. > When I say this "breaks" current functions, I don't mean they will never > work again. I mean that, due to different semantics in argument passing, > they will have to be changed. I'm assuming even the though cases like > PDOStatement::fetchAll() can be fixed. Yes, some functions with extremely complex corner cases of parameter parsing will have to be slightly changed. I'll think how to make this change easier. Of course, for this functions notion of default parameters won't work - we may even introduce some API to tell zend_parse_parameters about it. But for many other functions it may work just fine. For example, in the same PDO you have: bool PDOStatement::bindColumn ( mixed $column , mixed &$param [, int $type [, int $maxlen [, mixed $driverdata ]]] ) Now, what you do if you want to supply $driverdata but don't care about max length? We have two problems here: 1. Defaults are not documented, so you have zero idea how to get default behavior without looking into C code. 2. Defaults could change and you'd have to change your code. Skipping parameters would work here just fine and will use the same defaults the code uses, with zero pain to the user. > mt_srand() was a bad example. But let's supposed it didn't initialize > seed. It would be perfectly correct under current semantics, but as far as > I understand under the patch mt_srand(default) would result in > uninitialized data being used. If it didn't initialize seed, it would be a bug which even now needs to be fixed. You're not supposed to pass uninitialized values for default args into zend_parse_parameters, if you code does that, please fix it ASAP. > All it does is check for (PHP) NULLs before using zpp with "l", because > "l" would convert the NULL to 0 and I want to distinguish the two cases, > so that I can use NULL to the same effect of not passing the argument. > This was actually discussed in a pull request a few weeks ago. This seems to be a very unusual special case then, which has very little to do with topic at hand. Probably unique case in our code. Maybe we need to change zend_parse_parameters API or your function API or do some other good solution for it, but it's offtopic for now. Feel free to open a new thread on that, but for purposes of this one the conclusion is - yes, if you ignore system APIs then there's some work to be done there. I'll scan the code for such functions and see how to fix it best, thanks for bringing this issue to my attention. I do not see however that it somehow invalidates the concept, as 99% of the functions do not do that and you're not supposed to do that except in very special circumstances. > Quickly skimming the output with shows that in some cases it's multiline > calls, but those are in a clear minority (most are in if/switch > statements). And remember, this is just PHP core, a small fraction of all > extensions. Again, unless you ignore zend_parse_parameters API and cook your own parsing, your extension is just fine, which will cover about 99% of them. For the rest, I'll look for a solution. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
