put utility functions at the bottom of the script

[weepy]

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]

+1

[benekastah]

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

[michaelficarra]

related: satyr/coco@63d66d7

[jashkenas]

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]

@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]

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.

[paulmillr]

👍 (+1)

[michaelficarra]

related: 0199515 and the commit comments

[jussiry]

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

[michaelficarra]

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

[weepy]

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 <
[email protected]>wrote:

+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:
#1638 (comment)

[michaelficarra]

@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]

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]

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

[jashkenas]

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

[michaelficarra]

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]

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]

@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]

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.