Hacker News Reader

Comment by fourseventy | Hacker News Reader

"foo(x:, y:) is a syntax sugar of foo(x: x, y: y)"

This syntax sugar is a nightmare to me. Very confusing and for what? To save 2 keystrokes?

Keyword args are real nice for maintaining API compatibility but they're commonly passed down through the call stack resulting in a lot of:

"foo(arg, my_keyword1: my_keyword1, my_keyword2: my_keyword2, my_keyword3: my_keyword3)"

that now becomes:

"foo(arg, my_keyword1:, my_keyword2:, my_keyword3:)"

that is just a bit less for your eyes to have to digest and parse, although i can see leaving the trailing colon off as being a common bug.

sometimes you can just double splat both the signature and the wrapped invocation, but if you need to peel off kwargs in the wrapper method then you're stuck passing them all back in, or else you fall back to pulling kwargs out of a hash (plus you lose some level of auto-documentation in the method signature that way).

it'd be kind of nice to have a literal which could be passed into the method invocation that would expand out to all the kwargs that were passed, while still being explicit in the definition.

While yes, parameter names are usually longer than 1 character, I'm super disappointed that Ruby has introduced this. I hate hate HATE this in JS. Sure, it's easier to write, but my brain always has to do a small double-take as to what I'm looking at while reading as it looks almost identical to destructuring.

Also, how is this going to work in function heads? `def foo(bar:)` means that `bar` is a required keyword. Is it going to have to be `def foo({bar:})`? In that case, it's going to come off as a potential style error to many people.

My bad, the example illustrates in a function head. So how are require keyword args going to work now?

Oh wait, it's function definition vs callsite (duh). This is still unnecessary confusion.

It's only two keystrokes if your parameters are single characters.

  def some_method(with_longer_parameters: with_longer_parameters)
    do_something(with_longer_parameters)
  end

  def some_method(with_longer_parameters:)
    do_something(with_longer_parameters)
  end

Is it to spare keystrokes in method definition, or rather, in method invocation?

Your second definition reads that `with_longer_parameters` is a keyword argument with no default.

Still, you've illustrated the keystroke savings with your choice of parameter names :-)

Yeah, should be invocation, there's a nice example on the feature request (https://bugs.ruby-lang.org/issues/14579):

  def login(username: ENV["USER"], password:)
    p(username:, password:)
  end

  login(password: "xxx") #=> {:username=>"shugo", :password=>"xxx"}

I really wish there was a command to `un-sugar` a script - especially intelligently built into editors.

That way - if you're new to a language and don't want to deal with all the cognitive overhead of syntactic sugar (or if you just find some particular feature really complicated) - you could "un-see" it.

> To save 2 keystrokes?

A lot more keystrokes if you are using meaningful argument and/or hash key names, but the big benefit is, IMO, readability (at least, that's the big benefit I see with the very similar syntax in JS.)

I just don't see the readability arguments. I think it hurts readability in a big way, especially in JS where it can be mistaken for destructuring. I've seen firsthand people who defend this syntax get confused. Sure, it's brief confusion, but if anything introduces any kind of confusion at all, I don't see the benefit. `foo: foo` is verbose, sure, but I don't know how one could argue that it isn't readable. It's about as clear as you can get.

I don't find it that confusing. Parameter names are usually longer than one character.

I highly doubt that any such feature is introduced to save keystrokes.

If you want to save keystrokes, Ruby is probably not your language. And you also really need to invest some time in your editor/IDE.

The sugar is that it removes redundancy and adds DRY:

> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Now, the value for DRY is minimal here: `referer_acceptence_header: referrer_acceptance_header` is quite easy to spot (and there too: if these are your bugs, you probably need to invest some time in your editor/IDE), but avoiding it alltogether in the language is always nice.

Reply on news.ycombinator.com