Hacker News Reader

Comment by mistercow | Hacker News Reader

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).

View on HN

> 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.

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).

> 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.

> 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.

* 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.

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?

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.

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.

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.)

>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?

>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.

Reply on news.ycombinator.com