> Out of interest, how does coffeescript scale, and can it start to get unreadable?
It works well enough if your API design fits the language's expectations. This generally means your function calls take arguments in the order: normal args, onlyOneObject, callback.
How well it scales is sort of a taste question. I like that getters/setters and some event handlers tend to be one line. Here's a pair of functions I actually wrote today (I'm building a proprietary wysiwyg text editor that isn't using contentEditable)
getBlocks: -> @_breakText(block.get('value'), block.getLineBreaks()) for block in @blocks
getSelection: -> try start: @input.selectionStart, end: @input.selectionEnd
Here's a random longer function:
_getWords: ->
if @words.length
@words
else
@_doWrap()
words = []
pos = 0
size = 0
Y.all(@wrapSelector).each (el) ->
size = el.get('text').length
pos += size
r = el.get 'region'
words.push el: el
size: size
pos: pos
top: r.top
left: r.left
right: r.right
bottom: r.bottom
@words = words
You'll either think these are neat or that they're horrible. Note that the first is a comprehension and the second is a try/catch block returning an object (it can fail in some older gecko browsers if the page is still loading).
> in particular, the constructor implicitly declaring member variables
I think this is excessively cute as well and don't use it. Nor do I use the `x = {a, b}` producing `x = {a:a, b:b}` trick, which causes problems with implicit object parsing when the object isn't the last argument to the function.
> In particular, is there a clear unambiguous grammar for it anywhere? I can't find one.
There is not and there probably won't ever be. Doing one would be complicated quite a bit by the rewriting pass that happens before the compiler starts working on the code. A grammar for the resulting, unambiguous code wouldn't be too hard but that comes from the rewriter handling most of the hard corner cases.
Comments
> Out of interest, how does coffeescript scale, and can it start to get unreadable?
It works well enough if your API design fits the language's expectations. This generally means your function calls take arguments in the order: normal args, onlyOneObject, callback.
How well it scales is sort of a taste question. I like that getters/setters and some event handlers tend to be one line. Here's a pair of functions I actually wrote today (I'm building a proprietary wysiwyg text editor that isn't using contentEditable)
Here's a random longer function: You'll either think these are neat or that they're horrible. Note that the first is a comprehension and the second is a try/catch block returning an object (it can fail in some older gecko browsers if the page is still loading).> in particular, the constructor implicitly declaring member variables
I think this is excessively cute as well and don't use it. Nor do I use the `x = {a, b}` producing `x = {a:a, b:b}` trick, which causes problems with implicit object parsing when the object isn't the last argument to the function.
> In particular, is there a clear unambiguous grammar for it anywhere? I can't find one.
There is not and there probably won't ever be. Doing one would be complicated quite a bit by the rewriting pass that happens before the compiler starts working on the code. A grammar for the resulting, unambiguous code wouldn't be too hard but that comes from the rewriter handling most of the hard corner cases.
I've started preferring returning early instead of if-else. So:
this approach makes the code read almost like English.