-
-
Save jimmycuadra/1215863 to your computer and use it in GitHub Desktop.
# Given a function that accepts a function followed by a non-function argument... | |
foo = (callback, name) -> | |
console.log "Calling callback #{name}..." | |
callback() | |
# you end up with a line starting with | |
# a comma which just feels wrong... | |
foo -> | |
console.log "Callback called!" | |
, "bar" | |
# or an awkard set of parens which generates | |
# unnecessary parens in the compiled source... | |
foo (-> | |
console.log "Callback called!" | |
), "bar" | |
# or a syntax error. | |
foo -> | |
console.log("Callback called!"), "bar" | |
# Wat do? What's the preferred way to write this? |
Is there a drawback to the extra parens in the generated code? This looks rather nice to me:
q.when createRouteDone,
((value) ->
console.log value),
(reason) ->
console.log reason
That's great! It turns out the extra parens aren't even needed in that case. This works too:
q.when createRouteDone,
(value) ->
console.log value,
(reason) ->
console.log reason,
"non-function parameter"
Without the first argument, it seems you need parens around the whole thing, but it still looks very good to me:
q.when(
(value) ->
console.log value,
(reason) ->
console.log reason,
"non-function parameter"
)
/cc @jashkenas, @reshun
@jimmycuadra, in your last version, the commas also aren’t necessary:
q.when(
(value) ->
console.log value
(reason) ->
console.log reason
"non-function parameter"
)
I have to admit though that I do find it a bit inconsistent/odd that when arguments are an object (key/value), indentation alone is enough to indicate calling:
somefunc
foo: '1'
bar: '2'
but when they’re just positional arguments (whether functions or not), there’s a requirement to either add parentheses, or put one argument and a comma on the same line as the call:
somefunc(
'yay'
(spam) -> eggs
)
or:
somefunc 'yay',
(spam) -> 'eggs'
I’d personally prefer if this was also interpreted as a call instead of a syntax error:
somefunc
'yay'
(spam) -> 'eggs'
I doubt it. It's nothing more than a style point, and it'll be hard to find a syntax that makes arbitrary numbers of inline functions combined in any kind of expression into something more readable than properly factored out and named small functions.
That said, if you come up with something you think is groovy -- please open a ticket for it.