4 ms·

Yes. Why pay runtime cost when there exists a dev and compile time solution? An good IDE like WebStorm will show the parameter variable names, even inline w/ou

Yes. Why pay runtime cost when there exists a dev and compile time solution? An good IDE like WebStorm will show the parameter variable names, even inline w/out needing to hover, providing the exact same info as RORO. On top of that use JSDoc to provide type info and documentation that shows as a tooltip. Or go whole hog and use Typescript.

presentation 5y ago
When you have multiple parameters that are the same type, though, that isn’t foolproof. Maybe don’t do it everywhere, but do do it when misuse is likely (function foo(a: string, b: string, c: string): [string, string, string])
- eevilspock 5y ago
  How is the RORO version better? function foo({a: string, b: string, c: string}) Give the params proper names, and the IDE will reveal them (inline even!) without RORO or its costs. Sure, for a return value like that, use an object with proper names. But that’s been a best practice without “RORO”.
  - presentation 5y ago
    Sorry, my example was bad - my point is that if you have it literally be named parameters in the RORO case there’s much lower chance to screw it up since the labels are apparent without needing to hover or trigger any kind of dialog. Chance you’ll mix them up just goes down, so while in theory it’s basically the same as the editor help case, in practice it’s way more foolproof. Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO!
    - eevilspock 5y ago
      > Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO! Looks like you missed what I wrote (twice). They do. Others have pointed out that VSCode supports it too. Search the comments for "inlay hints". You also are shown the parameter names and types when writing the function call.
      - presentation 5y ago
        Oh I’m dumb, thanks for clarifying!

presentation 5y ago

When you have multiple parameters that are the same type, though, that isn’t foolproof. Maybe don’t do it everywhere, but do do it when misuse is likely (function foo(a: string, b: string, c: string): [string, string, string])

eevilspock 5y ago
How is the RORO version better? function foo({a: string, b: string, c: string}) Give the params proper names, and the IDE will reveal them (inline even!) without RORO or its costs. Sure, for a return value like that, use an object with proper names. But that’s been a best practice without “RORO”.
- presentation 5y ago
  Sorry, my example was bad - my point is that if you have it literally be named parameters in the RORO case there’s much lower chance to screw it up since the labels are apparent without needing to hover or trigger any kind of dialog. Chance you’ll mix them up just goes down, so while in theory it’s basically the same as the editor help case, in practice it’s way more foolproof. Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO!
  - eevilspock 5y ago
    > Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO! Looks like you missed what I wrote (twice). They do. Others have pointed out that VSCode supports it too. Search the comments for "inlay hints". You also are shown the parameter names and types when writing the function call.
    - presentation 5y ago
      Oh I’m dumb, thanks for clarifying!