arrow function syntax simplified

Allen Wirfs-Brock allen at
Sun Apr 1 11:08:03 PDT 2012

On Apr 1, 2012, at 8:07 AM, Quildreen Motta wrote:

> Is there any particular reason optionally dynamic `this' got ditched from the current arrow syntax proposal? It's one thing that, I think, would make it more useful than just being used for inline callbacks.

Yes, because it is unnecessary and would just add more confusion to the already too confused understanding of "this" by most JS programmers.

> Plus, with a syntax like:
> ---
> let ps = { lookahead: (this, n) => { this.current().slice(0, n || 1) }
> , current: (this) => { this.text.slice(this.offset) }
> , move: (this, n) => { this.clone(this.text, this.offset + 1) }
> , clone: (this, text, offset) => { let r = Object.create(this)
> , r.offset = offset || 0
> , r.text = text || '' }
> }
> ---

How is the above better (ignoring any controversy about line-beginning separators) than:

let ps = {
   lookahead ( n) { this.current().slice(0, n || 1) },
   current()  { this.text.slice(this.offset) },
   move(n)  { this.clone(this.text, this.offset + 1) },
   clone(text, offset)  {
      let r = Object.create(this);
      r.offset = offset || 0;
      r.text = text || '';

> You'd perhaps avoid some of the confusion on dynamic `this' by making it explicit that `this' is just an additional parameter passed over to the function — albeit implicitly.

"this" isn't just an additional parameter and trying to turn it into such just creates more confusions. this (aka self) is a characteristic feature of object-oriented methods, not of functions. Methods only have meaning in the context of an object.  It is essential to the OO programming model that this/self is dynamically bounds  to the object that is the target of each method invocation.  In a well designed OO language the method invocation target is syntactically distinct from "other parameters".  If this didn't have special OO semantics there would be no reason to have special syntax and semantics for defining/accessing this within a function.  However, in that case you don't have a OO language, instead you have a functional language that is used to provide a (low fidelity) simulation of OO constructs. 

The confusion about this in JS comes from at least four things.
1) It is too easy to define a "method" (a function that uses a dynamic per-invocation this binding) that is not directly associated with an object (or class/prototype). 
   eg: var f = function() {}; 
2) In classic JS there was no syntax that distinguished the intended definition of a method from a function, other than the appearance of this in the body of the function.
3) It is too easy to extract a method from an object (or class/prototype), breaking the association between the method and object.
    eg: var g = String.splice;
4) It is too easy to call a disassociated method without an object association as if it was a regular function
   eg: f();    

The confusion is only worsen by things like jQuery choosing to exploit such disassociated methods to create non-OO idioms using this

> It seems to work for Python, though there `self' is bound at the instantiation time.

I don't believe this is correct, if you mean object instantiation time.  You can view obj.meth in Python as a left-curry operation that creates a new function where the first parameter of meth is pre-bound to obj.  This is why Python does not have issue 3 above. 

Regardless, Python is also a retrofitted OO language where arguably objects are even less central to the language than in JS.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list