put utility functions at the bottom of the script #1638

weepy opened this Issue Aug 30, 2011 · 19 comments


None yet
8 participants

weepy commented Aug 30, 2011

At the moment, CoffeeScript puts the utility functions at the top of the script (as it does with all other variables). Unfortunately This causes the preamble of the file to be quite long - and it pushes line numbers further out.

If named functions were used instead, the functions could be placed at the bottom of the file as they would still be in scope.

Here's an example as a gist : https://gist.github.com/1180503


michaelficarra commented Aug 30, 2011


+1 (it would be pretty cool to actually have Google+ buttons here)


michaelficarra commented Sep 1, 2011


jashkenas commented Sep 12, 2011

I'm conflicted about this one.

I agree that, as compiler output, it's great to leave the boilerplate out of the way as much as possible.

That said, there's a reason that CoffeeScript doesn't allow function declarations -- it's truly bizarre to use a lexically-scoped function before it's even declared or defined. When reading a compiled JS file, you'd be seeing __extends called as a function, when it very well looks like an undefined value to you at that point.

Is it worth giving up one sense of readability in favor of the other?


michaelficarra commented Sep 12, 2011

@jashkenas: (in my opinion) Yes. Once you read a single coffeescript output, you'll know about these. You don't need them getting in your way on subsequent inspections.


davidchambers commented Sep 12, 2011

The fact that these names begin with __ makes it clear to the reader that these functions are special in some way. I agree with @michaelficarra that hoisting wouldn't cause much confusion in this case. I'm not opposed to the proposal.

👍 (+1)


michaelficarra commented Sep 19, 2011

jussiry commented Sep 29, 2011

+1 Though this becomes unnecessary when the debugging improves to show the actual line of an error.


michaelficarra commented Sep 29, 2011

@jussiry: this has nothing to do with line mapping and everything to do with readability.

weepy commented Sep 29, 2011

debugging improves to show the actual line of an error.

out of interest : is there any work on making this happen ?

On Thu, Sep 29, 2011 at 9:15 PM, jussiry <

+1 Though this becomes unnecessary when the debugging improves to show the
actual line of an error.

Reply to this email directly or view it on GitHub:
jashkenas#1638 (comment)


michaelficarra commented Sep 29, 2011

@weepy: see my comment above with the link to the commit comments from 0199515.

This could easily be done in 20 minutes by someone willing to put in the time. Like you. Even an inexperienced dev. would probably be able to fix it in under an hour. I'd love to -- I think it would be rather fun -- but I almost always have much higher priority tasks than having fun.


jashkenas commented Sep 29, 2011

I'm afraid that wrapping all uses of __indexOf in an extra function call isn't really acceptable, performance-wise. It should stay an expression.


michaelficarra commented Sep 29, 2011

@jashkenas: it's only the first use, not every one. Take a closer look.


jashkenas commented Sep 30, 2011

Cute. Isn't that sort of name re-use exactly the thing that old IE's will choke on?


michaelficarra commented Sep 30, 2011

Nope, I believe that occurs when assigning named function expressions to variables of the same name. Since we're not naming our function expressions, we should be fine. Though someone please correct me if I'm wrong; I have no way to test on IE.

weepy commented Sep 30, 2011

michaelficarra : I can't see how the commit really relates to my comment which was asking about whether it was possible to report on the actual source error line number? Obviously it makes the line numbers less wrong, but the problem still exists ?


michaelficarra commented Sep 30, 2011

@weepy: huh, I thought this proposal was mostly about the readability of the output. There won't be a 1:1 mapping of coffee to JS lines any time soon. See #558 for that kind of discussion.


GeoffreyBooth commented Apr 26, 2017

As of #4526 we have only one-liner helper functions, so the readability issue is less urgent. This doesn’t appear to be a priority, so I’m closing the issue. If someone wants to submit a PR that improves things, it would be welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment