5 ms·

Great! A few things that are rather addressing the Harmony proposal: - `this` in arrow functions: Now this is breaking the standard behavior AND strict mode.

Great! A few things that are rather addressing the Harmony proposal: - `this` in arrow functions: Now this is breaking the standard behavior AND strict mode. I understand that we're running out of reserved words for this, but maybe it shouldn't have been `this` with different semantics. (I would expect all (near-)future extensions to be compliant with strict mode.) - explicit `set()` and `get()` methods of Maps and WeakMaps: Why make them explicit and not implicit getters and setters (by subscript) like with associative arrays? Why another approach for the same thing? These parts of the proposal are prone to cause some irritations, since they are adding duplicate behavior or syntax to existing approaches ... Edit: I do understand that using subscripts in assignments to Maps and WeakMaps would produce some inconsistency on the other hand, since these subscripts would not translate to names (or rather to some hash-signature), so there's always a trade-off.

untog 13y ago
With regard to arrow functions, I'm a big fan of how CoffeeScript does it: -> no special consideration for 'this', works like function() => binds 'this' to parent's 'this'
- masswerk 13y ago
  In my view on `this`, changing the semantics would always harm the generality of functions as first class entities. In case I would assign a function to an object as a method, what would this mean for the semantics of `this`? Evaluating the this-object just as late as possible gives a general approach that isn't prone to fail. By changing semantics, we're always introducing some edge-cases, for which there would have to be special behavior and constraints to be defined. Even with binding there would have to be some constraints to be added. (We have been doing great things with the current implementation for nearly 20 years by now, so it can't be that wrong.) Personally, I would suggest the introduction of another variable, providing a "sticky this", which would stay bound to the this-object of the scope, the function was declared in. But what would be the reserved word to be used for it? (This would have to be restricted to arrow-functions, since there would be inconsistencies when assigning a method to an other object.)
  - masswerk 13y ago
    Edit: I think, explicitly asserting the binding by an assignment ("var that = this;") isn't the worst option and you may always trace back the variable to the binding-point. It may be an extra line of code, but we can live with that perfectly.
  - likeclockwork 13y ago
    It also makes the arrow shorthand less useful. Instead of -> {...} replacing function() {...} We get => {...} replacing (function() {...}).bind(this) Why should the less common case get the more convenient syntax? Especially considering when we already have Function.prototype.bind to do this. How could they possibly agree on this but not the thin arrow?
    - masswerk 13y ago
      There has been some discussion lately of JS being too verbose – this seems to be adding semantic sugar to address this. But introducing ambiguous semantics is quite an other thing.
    - camus2 13y ago
      I really hate the technical choice TC39 made with the arrow function. IT should have been a replacement for ANY kindof function. This is a total let down. Coffeescript syntax makes way more sense.
      - cpeterso 13y ago
        How does an arrow function's implicit bind(this) poses a problem or limits generality? (Honest question; I'm not a JS wizard.)
        camus2 13y ago
        > How does an arrow function's implicit bind(this) poses a problem or limits generality? Well you cant use it unbound. I dont want to declare functions bound to a scope I want a quick way to declare functions.
angersock 13y ago
For set() and get(), I'm betting its because you can override the handling of attribute accessors on an object--this avoids that confusion.
- masswerk 13y ago
  Or it could be some kind of "cargo cult" from the implementation in an other language, considering some of the popular writings and discussion in the last time. Personally, I would prefer JS "doing it the JS-way", rather than overloading paradigms by introducing implementation schemes from other languages. (Is JS prone to become a "Frankenstein language"?) I'm hoping you're right with your guess, regarding the motivations behind it.
jlongster 13y ago
Arrow functions don't break anything, they just add a little bit of complexity. And trust me, once you start using them, you'll never go back. That is one thing that TC39 absolutely got right; it solved a direct pain point in JS code and it's far easier to write good code with it. I work on the Firefox Debugger, and all the devtools use ES6 extensively, especially arrow functions. They aren't confusing. Almost always, `this` refers to the object instance that you are working on, and arrow functions allow you to do quick functional programming inside the methods. It's beautiful.
- mnemonik 13y ago
  Yeah, pretty much the only time you want non-arrow functions is for prototype methods (but once ES6 classes are implemented, you can use that syntax and it will be less verbose anyways). In almost every other case you either don't care about `this` or you want to use the containing function's `this` value. Arrow functions are perfect for these cases.
  - masswerk 13y ago
    I would just point out the ambiguity while working with legacy code and ES6 applications. (A separate name would have been fine. But of course, there is the reserved names problem.) From a practical perspective, we will have to deal with IE 8 and co for another 10 years at least. So we will have to "come back" all the time.
- masswerk 13y ago
  But the same `this` will have different semantics, depending on the context (is it a function or object, or is it an arrow function?). Also, strict mode will be ignored for this (rather than overriding standard behavior). This is introducing ambiguity in two separate fields. A not-so-serious proposal: Since everyone is overwriting the variable "self", we could reuse the variable "parent" for the same reasons in this case.
- deleted 13y ago
  [deleted]
- 13y ago
bzbarsky 13y ago
One reason to not make get() just be [] is that people wanted some methods on Map and WeakMap. Say you have a Map named 'm' and you do m.clear(). Keep in mind that '.' is just syntactic sugar in JS, so this is by definition the same as m["clear"](). But now you have to worry about what happens if someone uses "clear" as a key for the Map. Does that make it impossible to clear the map? Impossible to retrieve the key? Reinstate the e4x behavior where x.y() and x.y.call(x) would do different things? Something else? These concerns, which come up all the time with the use of objects as associative arrays, are why Map and WeakMap have explicit getter/setter methods. That way you can tell when you're working with the map part and when you're just treating it like an object with methods (clear, forEach, entries, keys, size, values) on it.

untog 13y ago

With regard to arrow functions, I'm a big fan of how CoffeeScript does it: -> no special consideration for 'this', works like function() => binds 'this' to parent's 'this'

masswerk 13y ago
In my view on `this`, changing the semantics would always harm the generality of functions as first class entities. In case I would assign a function to an object as a method, what would this mean for the semantics of `this`? Evaluating the this-object just as late as possible gives a general approach that isn't prone to fail. By changing semantics, we're always introducing some edge-cases, for which there would have to be special behavior and constraints to be defined. Even with binding there would have to be some constraints to be added. (We have been doing great things with the current implementation for nearly 20 years by now, so it can't be that wrong.) Personally, I would suggest the introduction of another variable, providing a "sticky this", which would stay bound to the this-object of the scope, the function was declared in. But what would be the reserved word to be used for it? (This would have to be restricted to arrow-functions, since there would be inconsistencies when assigning a method to an other object.)
- masswerk 13y ago
  Edit: I think, explicitly asserting the binding by an assignment ("var that = this;") isn't the worst option and you may always trace back the variable to the binding-point. It may be an extra line of code, but we can live with that perfectly.
- likeclockwork 13y ago
  It also makes the arrow shorthand less useful. Instead of -> {...} replacing function() {...} We get => {...} replacing (function() {...}).bind(this) Why should the less common case get the more convenient syntax? Especially considering when we already have Function.prototype.bind to do this. How could they possibly agree on this but not the thin arrow?
  - masswerk 13y ago
    There has been some discussion lately of JS being too verbose – this seems to be adding semantic sugar to address this. But introducing ambiguous semantics is quite an other thing.
  - camus2 13y ago
    I really hate the technical choice TC39 made with the arrow function. IT should have been a replacement for ANY kindof function. This is a total let down. Coffeescript syntax makes way more sense.
    - cpeterso 13y ago
      How does an arrow function's implicit bind(this) poses a problem or limits generality? (Honest question; I'm not a JS wizard.)
      - camus2 13y ago
        > How does an arrow function's implicit bind(this) poses a problem or limits generality? Well you cant use it unbound. I dont want to declare functions bound to a scope I want a quick way to declare functions.

angersock 13y ago

For set() and get(), I'm betting its because you can override the handling of attribute accessors on an object--this avoids that confusion.

masswerk 13y ago
Or it could be some kind of "cargo cult" from the implementation in an other language, considering some of the popular writings and discussion in the last time. Personally, I would prefer JS "doing it the JS-way", rather than overloading paradigms by introducing implementation schemes from other languages. (Is JS prone to become a "Frankenstein language"?) I'm hoping you're right with your guess, regarding the motivations behind it.

jlongster 13y ago

Arrow functions don't break anything, they just add a little bit of complexity. And trust me, once you start using them, you'll never go back. That is one thing that TC39 absolutely got right; it solved a direct pain point in JS code and it's far easier to write good code with it. I work on the Firefox Debugger, and all the devtools use ES6 extensively, especially arrow functions. They aren't confusing. Almost always, `this` refers to the object instance that you are working on, and arrow functions allow you to do quick functional programming inside the methods. It's beautiful.

mnemonik 13y ago
Yeah, pretty much the only time you want non-arrow functions is for prototype methods (but once ES6 classes are implemented, you can use that syntax and it will be less verbose anyways). In almost every other case you either don't care about `this` or you want to use the containing function's `this` value. Arrow functions are perfect for these cases.
- masswerk 13y ago
  I would just point out the ambiguity while working with legacy code and ES6 applications. (A separate name would have been fine. But of course, there is the reserved names problem.) From a practical perspective, we will have to deal with IE 8 and co for another 10 years at least. So we will have to "come back" all the time.
masswerk 13y ago
But the same `this` will have different semantics, depending on the context (is it a function or object, or is it an arrow function?). Also, strict mode will be ignored for this (rather than overriding standard behavior). This is introducing ambiguity in two separate fields. A not-so-serious proposal: Since everyone is overwriting the variable "self", we could reuse the variable "parent" for the same reasons in this case.
deleted 13y ago
[deleted]
13y ago

bzbarsky 13y ago

One reason to not make get() just be [] is that people wanted some methods on Map and WeakMap. Say you have a Map named 'm' and you do m.clear(). Keep in mind that '.' is just syntactic sugar in JS, so this is by definition the same as m["clear"](). But now you have to worry about what happens if someone uses "clear" as a key for the Map. Does that make it impossible to clear the map? Impossible to retrieve the key? Reinstate the e4x behavior where x.y() and x.y.call(x) would do different things? Something else? These concerns, which come up all the time with the use of objects as associative arrays, are why Map and WeakMap have explicit getter/setter methods. That way you can tell when you're working with the map part and when you're just treating it like an object with methods (clear, forEach, entries, keys, size, values) on it.