On 21 October 2010 09:11, Stan Vass <sv_for...@fmethod.com> wrote: >>> Option 4 would probably be the worse one to go for. Looking any number >>> of languages that support defaults and you will see code like ... >>> >>> someFunction(param1,,,,,param7,,,,param11) >> >> It does get ugly fast for large numbers of arguments... >> But any function with more than a handful of arguments is already >> asking for trouble... >> >> At that point you should be passing in a data structure / instance / >> array or something other than so many parameters. >> > > The above example would have at least 10 arguments, so I'd also say it'd > look bad never mind the syntax. > > Also a subtle thing: if your email reader doesn't use fixed width font, it's > hard to appreciate the look of each approach in an actual code editor. > And I'd say commas next to each other appear quite readable, self-sufficient > in fixed-width font, not to mention self-explanatory. > > Using 'default' would raise more confusion, such as, is that valid: $foo = > default; bar($foo); > If it's made valid, i.e. if it acts as a constant, I suspect before long > people will be assigning 'default' as yet another alternative to a > false/null value, and we'll need yet another concept to resolve that. > If it's not made valid, it'll be counter-intuitive as it looks exactly like > a constant passed as an argument. > > Stan Vass
I'm not only talking about userland code here. There are MANY functions in PHP that utilise default parameters. In most cases the lesser used parameters are at the end of the parameter list and it more often than not, it makes sense to supply the preceding parameters. Yes, I know a bunch of commas, one after the other, is unreadable. I've seen VBA code! I want null to be null. Not to be interpreted as a value. If I pass a null to a function with a default, I'm specifically NOT setting the value. Null has no value. The default is the only option that should be used. This can only apply to scalars. Objects, resources and arrays should all have the =null option. I'm guessing that the issue with implementing this in core is that each function is responsible for the defaults in such a way that they cannot easily be abstracted to the parameter processing code. The parameter values are first set to their defaults and then overwritten by the parameter processing code. I think that, for scalars, if I've supplied null, there is no value to overwrite. Take this example. This is the first function in the manual that has an optional parameter. int apc_bin_dumpfile ( array $files , array $user_vars , string $filename [, int $flags [, resource $context ]] ) Arguments that have been raised about too many parameters ... how many is too many? Is 5 OK? Why not x? $flags has no default here, but it is an int, so I have to assign something (well, I don't the default is 0 and the documentation is out on this issue, but that's another issue). So, off I go read the manual to be redirected to another page to get the list of flags I can 'OR'. But, assuming the default was documented, the prototype would look more like int $flags = 0 So, I want to use the default. OK. 0 vs null in terms of code, 0 is shorter, but it means that if the default was to change (not with this function, but any function - and that could be userland), then allowing me to say "use whatever the default is" would certainly be the way to protect me. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
