4 ms·

I've always thought that named parameters, while useful as a pattern, were not entirely worthy of first class status. You can easily get the same functionality

I've always thought that named parameters, while useful as a pattern, were not entirely worthy of first class status. You can easily get the same functionality with a single associative array config parameter. That also has the additional benefit that the user of a function can reuse the config array, tweaking individual settings between multiple function calls. All in all, the amount of boilerplate you save by making named parameters first class is tiny (unless, of course, your language has some kind of preposterously verbose associative array constructor syntax, like PHP does).

masklinn 14y ago
> You can easily get the same functionality with a single associative array config parameter. Not really, you lose most of the validation and documentation, you get 2 levels of parameters (first-class positionals and second-class keywords), you may not correctly detect or handle redundant provisions, defaults may or may not work the same way (and correctly), and it's not possible to provide through keywords a parameter the function's implementer has defined as positional, even if that's clearer for the callsite. It works-ish, but it is and remains a hack and a pale shadow of first-class keyword parameters. On the other hand, I can get behind the inverse: keyword-only parameters and positionals by abusing arrays (à la Smalltalk, Self or Objective-C), in my experience that significantly increases the code's readability and flexibility. Though it hardly plays nicely with partial application. > That also has the additional benefit that the user of a function can reuse the config array parameter packing & unpacking takes care of that, it's not an advantage of "a single associative array". > the amount of boilerplate you save by making named parameters first class is tiny To get the same functionality as e.g. Python's kwargs, we're probably talking about half a dozen lines. In each function. That's not tiny.
- wdewind 14y ago
  What? The benefit is not saved lines, it's ease of expressing explicitness (ie: inline with the function call instead of throw assigning to variables above it). Please show an example of how this is saving lines in a way that's not comprable to simply doing multiple assigns on one line (ie: destroying readability).
  - masklinn 14y ago
    > What? The benefit is not saved lines Not sure what you're talking about. When somebody talks about "boilerplate", it's very much about the number of (setup/redundant) expressions/tokens having to be used to do something. > Please show an example of how this is saving lines in a way that's not comprable to simply doing multiple assigns on one line (ie: destroying readability). I would suggest actually reading my comment, that may give you a hint as to what I'm comparing and let you understand on your own how different it is.
    - deleted 14y ago
      [deleted]
- ericingram 14y ago
  > Not really, you lose most of the validation and documentation... This is only true if you don't replace these forms of documentation with something better, which I'd do.
  - masklinn 14y ago
    * Validation is not documentation, either it's there or it's not there, with built-in keyword arguments it's there, with a hash-hack it probably isn't. * Documenting a hash-hack will still require spelling out that one of the positional parameters is a hash, then diving into that hash to spell out the various keys. This adds one worthless level of indirections to first-class keyword parameters, which can just treat all parameters the same way for documentary purposes.
rll 14y ago
You mean 5.4's associative array syntax: func([$arg1,'name2'=>$arg2,$arg3]); is too verbose for you for a mix of named and non-named parameters? How would you shorten it?
- gburt 14y ago
  It's much improved in 5.4. I think the grandparent post's point was that prior to 5.4, this would've looked like func(array("arg1", "name2"=>"arg2", "arg3")); Which is much "uglier" than the new syntax.
- mistercow 14y ago
  Oh, yes 5.4 is a bit improved, but how would I shorten it? I'd drop the quotes around 'name2' whenever it was a legal identifier, and I'd ditch the hideous => symbol.
  - pacmon 14y ago
    I think dropping the quotes is a bad idea. This isn't javascript. However, I do agree about the => symbol. I would have preferred if in 5.4 they added support for ':' so, ['a':$b]. At which point, I'm sure someone will say that looks so similar to js syntax, why not drop the quotes? To which I say -personally- I just think it leads to more confusion. (Although for some reason I don't mind that in js - I know.. weird preferences.)
    - mistercow 14y ago
      >I think dropping the quotes is a bad idea. This isn't javascript. That doesn't sound like a legitimate reason to me. It's not javascript. So what?
batista 14y ago
>unless, of course, your language has some kind of preposterously verbose associative array constructor syntax, like PHP does array( => , => , ...) is "preposterously verbose? You should see some other languages for the "preposterously" part. Plus 5.4 has short array syntax.

masklinn 14y ago

> You can easily get the same functionality with a single associative array config parameter. Not really, you lose most of the validation and documentation, you get 2 levels of parameters (first-class positionals and second-class keywords), you may not correctly detect or handle redundant provisions, defaults may or may not work the same way (and correctly), and it's not possible to provide through keywords a parameter the function's implementer has defined as positional, even if that's clearer for the callsite. It works-ish, but it is and remains a hack and a pale shadow of first-class keyword parameters. On the other hand, I can get behind the inverse: keyword-only parameters and positionals by abusing arrays (à la Smalltalk, Self or Objective-C), in my experience that significantly increases the code's readability and flexibility. Though it hardly plays nicely with partial application. > That also has the additional benefit that the user of a function can reuse the config array parameter packing & unpacking takes care of that, it's not an advantage of "a single associative array". > the amount of boilerplate you save by making named parameters first class is tiny To get the same functionality as e.g. Python's kwargs, we're probably talking about half a dozen lines. In each function. That's not tiny.

wdewind 14y ago
What? The benefit is not saved lines, it's ease of expressing explicitness (ie: inline with the function call instead of throw assigning to variables above it). Please show an example of how this is saving lines in a way that's not comprable to simply doing multiple assigns on one line (ie: destroying readability).
- masklinn 14y ago
  > What? The benefit is not saved lines Not sure what you're talking about. When somebody talks about "boilerplate", it's very much about the number of (setup/redundant) expressions/tokens having to be used to do something. > Please show an example of how this is saving lines in a way that's not comprable to simply doing multiple assigns on one line (ie: destroying readability). I would suggest actually reading my comment, that may give you a hint as to what I'm comparing and let you understand on your own how different it is.
  - deleted 14y ago
    [deleted]
ericingram 14y ago
> Not really, you lose most of the validation and documentation... This is only true if you don't replace these forms of documentation with something better, which I'd do.
- masklinn 14y ago
  * Validation is not documentation, either it's there or it's not there, with built-in keyword arguments it's there, with a hash-hack it probably isn't. * Documenting a hash-hack will still require spelling out that one of the positional parameters is a hash, then diving into that hash to spell out the various keys. This adds one worthless level of indirections to first-class keyword parameters, which can just treat all parameters the same way for documentary purposes.

rll 14y ago

You mean 5.4's associative array syntax: func([$arg1,'name2'=>$arg2,$arg3]); is too verbose for you for a mix of named and non-named parameters? How would you shorten it?

gburt 14y ago
It's much improved in 5.4. I think the grandparent post's point was that prior to 5.4, this would've looked like func(array("arg1", "name2"=>"arg2", "arg3")); Which is much "uglier" than the new syntax.
mistercow 14y ago
Oh, yes 5.4 is a bit improved, but how would I shorten it? I'd drop the quotes around 'name2' whenever it was a legal identifier, and I'd ditch the hideous => symbol.
- pacmon 14y ago
  I think dropping the quotes is a bad idea. This isn't javascript. However, I do agree about the => symbol. I would have preferred if in 5.4 they added support for ':' so, ['a':$b]. At which point, I'm sure someone will say that looks so similar to js syntax, why not drop the quotes? To which I say -personally- I just think it leads to more confusion. (Although for some reason I don't mind that in js - I know.. weird preferences.)
  - mistercow 14y ago
    >I think dropping the quotes is a bad idea. This isn't javascript. That doesn't sound like a legitimate reason to me. It's not javascript. So what?

batista 14y ago

>unless, of course, your language has some kind of preposterously verbose associative array constructor syntax, like PHP does array( => , => , ...) is "preposterously verbose? You should see some other languages for the "preposterously" part. Plus 5.4 has short array syntax.