Ron Korving wrote:
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);
We've seen a large number of cases where named parameters would be
extremely useful. To each case, there has been a half baked attempt to
dismiss the usefulness of the purported design.
For example,
> If you have too many parameters that you want to start omitting
> parameters when calling a function, its probably time to refactor.
Refactor? If you have a number of required options to get a result,
refactoring isn't going to change that.
Also,
> And if you have many parameters to functions you still need to look at
> the definition (or documentation) to figure out what parameters the
> function takes. It's not a big problem to look at the order at the
> same time.
That's not the point, at all. It annoys me that good points are being
dismissed with such ridiculous counter-arguments.
No one is suggesting that people shouldn't look at the definition. Nor
that people have problems remembering parameter order (I do, but again,
not the point). In fact, named parameters allows people to quickly look
at the definition to see what options are available. This is one reason
named parameters are an improvement on associative array parsing.
The problem is when an option needs to be changed which just happens to
be at the very end of the function signature, function calls start
looking like this: foo(null, null, null, null, null, null, true);
Anyway, enough rebuttal. I think it's now incredibly obvious that the
wider community would like to see named parameters in PHP 6.
Are the PHP group prepared to accept and implement a named parameters patch?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
