4 ms·

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

onlyrealcuzzo 5y ago
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.
dragonwriter 5y ago
> 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.)
- sodapopcan 5y ago
  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.
mostlysimilar 5y ago
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 vs def some_method(with_longer_parameters:) do_something(with_longer_parameters) end
- cpb 5y ago
  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 :-)
  - kule 5y ago
    Yeah, should be invocation, there's a nice example on the feature request (https://bugs.ruby-lang.org/issues/14579 https://bugs.ruby-lang.org/issues/14579): def login(username: ENV["USER"], password:) p(username:, password:) end login(password: "xxx") #=> {:username=>"shugo", :password=>"xxx"}
nusaru 5y ago
I don't find it that confusing. Parameter names are usually longer than one character.
berkes 5y ago
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.
sodapopcan 5y ago
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.
- sodapopcan 5y ago
  My bad, the example illustrates in a function head. So how are require keyword args going to work now?
  - sodapopcan 5y ago
    Oh wait, it's function definition vs callsite (duh). This is still unnecessary confusion.
lamontcg 5y ago
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.

onlyrealcuzzo 5y ago

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.

dragonwriter 5y ago

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

sodapopcan 5y ago
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.

mostlysimilar 5y ago

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 vs def some_method(with_longer_parameters:) do_something(with_longer_parameters) end

cpb 5y ago
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 :-)
- kule 5y ago
  Yeah, should be invocation, there's a nice example on the feature request (https://bugs.ruby-lang.org/issues/14579 https://bugs.ruby-lang.org/issues/14579): def login(username: ENV["USER"], password:) p(username:, password:) end login(password: "xxx") #=> {:username=>"shugo", :password=>"xxx"}

nusaru 5y ago

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

berkes 5y ago

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.

sodapopcan 5y ago

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.

sodapopcan 5y ago
My bad, the example illustrates in a function head. So how are require keyword args going to work now?
- sodapopcan 5y ago
  Oh wait, it's function definition vs callsite (duh). This is still unnecessary confusion.

lamontcg 5y ago

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.