Live data from Hacker News

Brief Video: Rewriting JavaScript into CoffeeScript

ryanflorence.com

11–20 of 27 posts

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#11
post #8

Can someone explain the 'same name key:value shortcut' feature?

It's a DRY thing. Often in JS, object literals assign their keys to values of the same name -- you'll see a lot of this:

    $.ajax(url, {
      data: data,
      contentType: contentType,
      success: success,
      error: error
    });
... not so nice. So as a first stab, you can clean it up like so:

    $.ajax url, {data, contentType, success, error}
... but it's especially nice in the context of destructuring assignment, like for your Node.js imports, for example.

    {spawn, exec} = require 'child_process'

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#12
I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..).

When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like:

    test: (m) ->
      m(i) for i in this.set
Since I didn't really expect them to build up and return arrays of the results of invoking m, which at times could result in a method that would generate gigantic arrays that I would subsequently throw away, killing my performance.

I probably should have expected that, sure, and if you don't have to deal with too much data it probably won't matter.

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#13
post #7

Earlier quoted context omitted.

Since ?= looks so familiar, any chance of an elvis or defined-or operator in coffeescript? if a? then a else 0 becomes either a ?: 0 (if you like groovy) or a // 0 (if you like perl)

You've already got that. To cover my bases... The existential operator can be used infix: result = a ? 0 Or postfix (does "result" exist?) result? Or to conditionally assign, as we've seen above: result ?= a

Oh, sorry I missed that!

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#14
post #8

Can someone explain the 'same name key:value shortcut' feature?

It's a DRY thing. Often in JS, object literals assign their keys to values of the same name -- you'll see a lot of this: $.ajax(url, { data: data, contentType: contentType, success: success, error: error }); ... not so nice. So as a first stab, you can clean it up like so: $.ajax url, {data, contentType, success, error} ... but it's especially nice in the context of destructuring assignment, like for your Node.js imp…

Nice. Thanks Jeremy.

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#15
post #5

[deleted]

I'm not sure where you got that idea -- it's not at all true. "or=" is the same as "||=", and means: Assign the variable on the left to the value on the right if the variable is falsy. "?=" means: Assign the variable on the left to the value on the right if the variable does not yet exist (ie. is either "null" or "undefined"). Two different things, both useful.

Gotcha, thanks for the correction! I've removed my post. Could you clarify if or= still exists? I was reading the change log for 1.3.1 and I think I may have interpreted this line incorrectly "Conditional assignment of previously undefined variables a or= b is now considered a syntax error.". Thanks!

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#16

Earlier quoted context omitted.

I'm not sure where you got that idea -- it's not at all true. "or=" is the same as "||=", and means: Assign the variable on the left to the value on the right if the variable is falsy. "?=" means: Assign the variable on the left to the value on the right if the variable does not yet exist (ie. is either "null" or "undefined"). Two different things, both useful.

Gotcha, thanks for the correction! I've removed my post. Could you clarify if or= still exists? I was reading the change log for 1.3.1 and I think I may have interpreted this line incorrectly "Conditional assignment of previously undefined variables a or= b is now considered a syntax error.". Thanks!

My interpretation of your quote is that the feature is there, but if the LHS is undefined, then the error is caught by the compiler, rather than at run-time (what is the falsity of an undefined value?)

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#17
post #16

Earlier quoted context omitted.

Gotcha, thanks for the correction! I've removed my post. Could you clarify if or= still exists? I was reading the change log for 1.3.1 and I think I may have interpreted this line incorrectly "Conditional assignment of previously undefined variables a or= b is now considered a syntax error.". Thanks!

My interpretation of your quote is that the feature is there, but if the LHS is undefined, then the error is caught by the compiler, rather than at run-time (what is the falsity of an undefined value?)

Yea, you're correct. This has been one of those "duh" moments. Thanks for the reply!

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#18

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..). When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like: test: (m) -> m(i) for i in this.set Since I didn't really expect them to build up and return arrays of the r…

Out of curiosity ... if you love implicit returns in principle, then why would you dislike them in this context?

Certainly, you need to keep in mind the return value of a function while you're writing it -- if you don't want to return any value, then just "return". And it's definitely something that you need to keep more in mind while porting JS than when writing code from scratch. But given all that, would you really prefer explicit returns in CoffeeScript?

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#19
This is very cool, though I personally find postfix flow control confusing to read. The postfix loop with destructuring is especially odd to me. As I read left to right, I see variables that don't exist "yet" until I get to the later loop clause.

This is probably just a familiarity thing and I would get used to it, but compared to all of the other changes in the video which I think are pretty clean that stood out to me as a bit... iffy?

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#20

This is very cool, though I personally find postfix flow control confusing to read. The postfix loop with destructuring is especially odd to me. As I read left to right, I see variables that don't exist "yet" until I get to the later loop clause. This is probably just a familiarity thing and I would get used to it, but compared to all of the other changes in the video which I think are pretty clean that stood out to…

Agreed. I think there's a bit of LOC-golfing at work here. That loop is more nicely written as:

    for {handler, context} in @events[topic]
      handler.apply context, args
Post reply on HN