On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
<mich...@mjburgess.co.uk> wrote:
> The position of parameters and the name of the function must already be
> maintained... I dont see why appropriately naming variables is such a
> burden.
>
I wouldn't necessarily make this objection if this were a day-1
feature. But it does bother me somewhat that all of a sudden code
retro-actively starts supporting named parameters.
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' => 1, 'string' => 'Hello World');
Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere. So that's why I call this a nuisance. It just seems like a
very marginal gain for lots of potential headaches.
But I don't mean to make a mountain out of a molehill. After giving it
some thought, I'd like some consideration to be given to providing an
explicit syntax in the RFC at least so people consider all
alternatives.
I just don't think that giving people the ability to call a function
with two well ordered parameters by using named parameters is worth
causing all future code to diverge into two drastically different
calling styles.
My strong preference would be a syntax that separates the two types of
parameters, such as the following:
function func($a, $b, ...$params, [$c = 'foo', $d = 'bar'])
{
}
func($a, $b, $extra, 'd' => 'override');
Here $a and $b are not named parameters and must be present. Extra
positional parameters are sent to $params. The parameters enclosed in
square brackets must be passed in by name as the last parameters, but
can be omitted.
I don't like the $ on the named parameter when calling because it
implies that this works:
$d = 'c';
func($a, $b, $extra, $d => 'override');
Now is 'c' overridden or 'd'?
So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
