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() {this.foo()};
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.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
