On Sat, Sep 7, 2013 at 5:29 AM, Matthew Leverton <[email protected]> wrote:
>
> The big difference here is if I accept an options array, I understand
> that the keys are important and would never break backward
> compatibility by changing a parameter name. This isn't a case of "if
> you don't like it, then don't use it" because every function I create
> now has to respect the possibility of accepting named parameters,
> whether I care about it or not. And I sure hope every function I call
> is created by and maintained by somebody with those same
> sensibilities.
>
> My opinion is that this really isn't as cool as it sounds, especially
> since we have short array syntax. Again, I don't really care if it's
> accepted into PHP, but I think it will be more of a minor nuisance for
> me than anything else.
>
> --
> Matthew Leverton
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Hi, all
Would it be an option, to change the way named functions are declared?
This way you would mark a function explicitly as having named
parameters.
This increases the learning-curve for PHP, but for me, it seems a
valid approach ...
An example that comes to my mind, is to call this a "named" function
... Feel free to add a better keyword.
This would then look something like this:
named function functionHavingNamedParamsEnabled($firstParam, $secondParam) {}
function functionHavingNamedParamsDisabled($firstParam, $secondParam) {}
functionHavingNamedParamsEnabled( "secondParam" => "secondValue",
"firstParam" => "firstValue");
// Will work ...
functionHavingNamedParamsDisabled( "secondParam" => "secondValue",
"firstParam" => "firstValue");
// Will not work, because this function is not declared to support named params.
Just an idea for a compromise ..
What I don't like here would be if I'd have to add some cryptographic
char instead of a keyword to the definition of the function.
I, too, am quite neutral to this feature.
Bye,
Simon