Lexical versus dynamic "this"
On May 10, 2011, at 4:31 PM, Axel Rauschmayer wrote:
Quoting Andrew Dupont:
(b) the ->/=> distinction is, I think, too subtle. Rebinding dramatically changes the meaning of the function, so I'd prefer if the notation guaranteed that a user couldn't gloss over that by mistaking -> for => or vice/versa.
I agree. Are newbies ever going to be able to handle this? If we are going to overhaul function semantics, wouldn’t it make sense to adopt a more explicit approach?
myfunc(param1, param2) -> { ... } // lexical this var obj = { mymethod: (this, param1, param2) -> { ... } // dynamic this }
This is how Python handles methods. I think there were objections to this approach, but unfortunately I can neither remember them nor find them online.
No, this was still a possibility and I almost wrote it up at strawman:arrow_function_syntax -- but with (this) -> .... That was just gratuitously overlong and incompatible with CoffeeScript.
There's no arguing with the objection that => feels to close to -> and lexical-this is a major change deserving more significant syntactic differentiation. It's plausible, but if users often need the heavier syntax, they'll waste keystrokes and brain cells on it and curse us for not getting the "right default".
Usability is hard. I've seen zero evidence that CoffeeScript's fat-arrow is unusably terse and people are fooled into thinking it's as cheap as -> (if that's the concern). What is the problem?
myfunc(param1, param2) -> { ... } // lexical this var obj = { mymethod: (this, param1, param2) -> { ... } // dynamic this }
This is how Python handles methods. I think there were objections to this approach, but unfortunately I can neither remember them nor find them online.
No, this was still a possibility and I almost wrote it up at strawman:arrow_function_syntax -- but with (this) -> .... That was just gratuitously overlong and incompatible with CoffeeScript.
There's no arguing with the objection that => feels to close to -> and lexical-this is a major change deserving more significant syntactic differentiation. It's plausible, but if users often need the heavier syntax, they'll waste keystrokes and brain cells on it and curse us for not getting the "right default".
Usability is hard. I've seen zero evidence that CoffeeScript's fat-arrow is unusably terse and people are fooled into thinking it's as cheap as -> (if that's the concern). What is the problem?
I’m not emotionally invested in the explicit |this|. I know it from Python and Lua and like it there. It is also a nice visualization of the "shadowing" of |this|, in a way that should be easier to understand for newcomers.
On the other hand, CoffeeScript compatibility and terseness are valid arguments. Typing |this| for each method will be repetitive.
BTW: I find that the infix -> works well for object literals, where a prefix operator unnecessarily separates the method name from the parameter list.
To sum up: I don't lean either way, both solutions have pros and cons. Any solution that makes function expressions shorter is fine with me.
Another question: I find it conceptually clearer to distinguish between methods and functions, instead of between functions and functions with bound |this|. Wouldn’t it be better to use "->" for functions ("lighter", no |this| except for lexical access to |this|) and "=>" for methods ("heavier", |this| as an implicit parameter). Or does that deviate too much from current ES semantics?
Axel
On May 10, 2011, at 7:47 PM, Brendan Eich wrote:
Usability is hard. I've seen zero evidence that CoffeeScript's fat-arrow is unusably terse and people are fooled into thinking it's as cheap as -> (if that's the concern). What is the problem?
The problem comes from my (limited) experience reading CoffeeScript: not only is the arrow syntax light enough that I sometimes miss it entirely, but when I see it in code I often find myself not noticing whether it used -> or => until I go back and look at it again. I'm not worried that its terseness makes it unusable; I think it's easy to remember which is which when you're typing it. I worry that its terseness makes reading other people's code (or code you wrote months ago) harder to grok.
I freely admit this is a vague, hard-to-prove concern, but I mention it here in case other people feel the same way. I'm happy to go hunting for evidence if someone can suggest what I should be looking for.
Quoting Andrew Dupont:
I agree. Are newbies ever going to be able to handle this? If we are going to overhaul function semantics, wouldn’t it make sense to adopt a more explicit approach?
This is how Python handles methods. I think there were objections to this approach, but unfortunately I can neither remember them nor find them online.
I think I’ll get used to the infix operator, but would prefer if it could be prefix (easier on my eyes, easier to parse, closer to current syntactic style). Is the backslash already taken?
(x,y) x + y #(x) x +y // frozen
Quoting Andrew Dupont: > (b) the ->/=> distinction is, I think, too subtle. Rebinding dramatically changes the meaning of the function, so I'd prefer if the notation guaranteed that a user couldn't gloss over that by mistaking -> for => or vice/versa. I agree. Are newbies ever going to be able to handle this? If we are going to overhaul function semantics, wouldn’t it make sense to adopt a more explicit approach? > myfunc(param1, param2) -> { ... } // lexical this > var obj = { > mymethod: (this, param1, param2) -> { ... } // dynamic this > } This is how Python handles methods. I think there were objections to this approach, but unfortunately I can neither remember them nor find them online. I think I’ll get used to the infix operator, but would prefer if it could be prefix (easier on *my* eyes, easier to parse, closer to current syntactic style). Is the backslash already taken? \(x,y) x + y #\(x) x +y // frozen -- Dr. Axel Rauschmayer axel at rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com