6 ms·

Finally, after all these years, Named Arguments! https://stitcher.io/blog/php-8-named-arguments https://stitcher.io/blog/php-8-named-arguments

EGreg 6y ago
Look, 10 years ago I tried — really tried — to get the PHP team to adopt it. I am glad they finally came around: https://www.mail-archive.com/internals@lists.php.net/msg45871.html https://www.mail-archive.com/internals@lists.php.net/msg4587... Excerpt of the proposal: So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code. PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.
- Kim_Bruning 6y ago
  Thank you for your efforts back then. And now you stand vindicated!
  - EGreg 6y ago
    Somehow one guy was really sure it will never happen: https://www.mail-archive.com/internals@lists.php.net/msg48044.html https://www.mail-archive.com/internals@lists.php.net/msg4804...
baby 6y ago
I don't understand why pretty much no language does that these days. I think the argument is that your IDE should do this, and it does in some cases, but still...
- chmod775 6y ago
  You can get a much more powerful alternative for "free" if you support de-structuring assignments (in arguments). JavaScript Example: function test({a,b,c}) { console.log(c,b,a) }; test({ a: 1, b: 2, c: 3 }); If you have this there's really no need for named arguments anymore. If you add features to your de-structuring, your "named arguments" will have them too (things missing for JS specifically: optional objects, TS support to specify types for the destructured objects inline instead of repeating the entire thing).
  - TekMol 6y ago
    It is not more powerful. You cannot do this for example: function hello($name='Joe',$title='dear') { echo "Hello $title $name"; } hello('Sue'); Try here: https://3v4l.org/6MZHh https://3v4l.org/6MZHh With your object properties approach, you always have to use the variable "names".
    - bmn__ 6y ago
      Mixing implicit positional and named parameters is a misfeature. The named parameters should have a distinct syntax like other systems do, e.g. :$ twigil.
- ptx 6y ago
  Python, Kotlin and C# all support named arguments, and they're pretty popular languages. And also... there's Visual Basic.
  - Okawari 6y ago
    I guess you can add dart and maybe ruby and elixir if you accept that they treated as a map/keyword list on the receiving end of the function. Edit: Ruby apparently made them first class citizens back in 2014. Ive been oblivious to this for years... wow.
zackmorris 6y ago
Thanks for that! The only error I see in their implementation is that we can't use variables for the name like: $name = 'foo'; myFunction($name: 'bar'); Thankfully, we can still pass an array with the spread operator like: $name = 'foo'; $array = [$name => 'bar']; myFunction(...$array); I wonder if this would work: $name = 'foo'; myFunction(...[$name => 'bar']); Thankfully it's rather unlikely that someone would use a variable for the name anyway. Where this will bite people is when they do meta programming with functions that process functions and function signatures. Maybe I'm missing something, but I find this to be another tragically missed opportunity. It's just unnecessary friction where there didn't need to be any, which makes me sad. At least they can add variable name support someday, because it's easier to allow something restricted than restrict something that used to work. Hopefully there is a "good reason" for this oversight.
- tored 6y ago
  It works https://3v4l.org/qY3os https://3v4l.org/qY3os
throw_m239339 6y ago
i'm not sure it's a good thing readability wise. I would have liked to see struct definitions + adhoc struct definitions and destructuring instead of that. Some frameworks like Symfony relied too much on shoving unstructured array options as arguments though, so if it helps making API strictier...

EGreg 6y ago

Look, 10 years ago I tried — really tried — to get the PHP team to adopt it. I am glad they finally came around: https://www.mail-archive.com/internals@lists.php.net/msg45871.html https://www.mail-archive.com/internals@lists.php.net/msg4587... Excerpt of the proposal: So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code. PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.

Kim_Bruning 6y ago
Thank you for your efforts back then. And now you stand vindicated!
- EGreg 6y ago
  Somehow one guy was really sure it will never happen: https://www.mail-archive.com/internals@lists.php.net/msg48044.html https://www.mail-archive.com/internals@lists.php.net/msg4804...

baby 6y ago

I don't understand why pretty much no language does that these days. I think the argument is that your IDE should do this, and it does in some cases, but still...

chmod775 6y ago
You can get a much more powerful alternative for "free" if you support de-structuring assignments (in arguments). JavaScript Example: function test({a,b,c}) { console.log(c,b,a) }; test({ a: 1, b: 2, c: 3 }); If you have this there's really no need for named arguments anymore. If you add features to your de-structuring, your "named arguments" will have them too (things missing for JS specifically: optional objects, TS support to specify types for the destructured objects inline instead of repeating the entire thing).
- TekMol 6y ago
  It is not more powerful. You cannot do this for example: function hello($name='Joe',$title='dear') { echo "Hello $title $name"; } hello('Sue'); Try here: https://3v4l.org/6MZHh https://3v4l.org/6MZHh With your object properties approach, you always have to use the variable "names".
  - bmn__ 6y ago
    Mixing implicit positional and named parameters is a misfeature. The named parameters should have a distinct syntax like other systems do, e.g. :$ twigil.
ptx 6y ago
Python, Kotlin and C# all support named arguments, and they're pretty popular languages. And also... there's Visual Basic.
- Okawari 6y ago
  I guess you can add dart and maybe ruby and elixir if you accept that they treated as a map/keyword list on the receiving end of the function. Edit: Ruby apparently made them first class citizens back in 2014. Ive been oblivious to this for years... wow.

zackmorris 6y ago

Thanks for that! The only error I see in their implementation is that we can't use variables for the name like: $name = 'foo'; myFunction($name: 'bar'); Thankfully, we can still pass an array with the spread operator like: $name = 'foo'; $array = [$name => 'bar']; myFunction(...$array); I wonder if this would work: $name = 'foo'; myFunction(...[$name => 'bar']); Thankfully it's rather unlikely that someone would use a variable for the name anyway. Where this will bite people is when they do meta programming with functions that process functions and function signatures. Maybe I'm missing something, but I find this to be another tragically missed opportunity. It's just unnecessary friction where there didn't need to be any, which makes me sad. At least they can add variable name support someday, because it's easier to allow something restricted than restrict something that used to work. Hopefully there is a "good reason" for this oversight.

tored 6y ago
It works https://3v4l.org/qY3os https://3v4l.org/qY3os

throw_m239339 6y ago

i'm not sure it's a good thing readability wise. I would have liked to see struct definitions + adhoc struct definitions and destructuring instead of that. Some frameworks like Symfony relied too much on shoving unstructured array options as arguments though, so if it helps making API strictier...