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.
You can get that back without changing the proposal (ES6 comments,
ES5 code):
// wrap this-less f to capture dynamic 'this' as explicit parameter
// function fn(f) { return function(..args) { return f(this,..args) } }
//
function fn(f) { return function() {
return
f.apply(null,[this].concat(Array.prototype.slice.call(arguments))) }
}
// access dynamic 'this' as lexical 'it'
// obj = { id: "obj", f: fn( (it,msg)=>{ console.log(msg+it.id) } ) }
//
var obj = { id: "obj",f: fn( function(it,msg){ console.log(msg+it.id) } ) };
obj.f("hi, "); // outputs "hi, obj"
Claus
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 || '' }
}
---
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. It seems to work for Python, though there
`self' is bound at the instantiation time.
On 01/04/12 05:47, Axel Rauschmayer wrote:
AFAIKT, Crockford is referring to an older version of the proposal.
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
[email protected]
Home: http://rauschma.de
Blog: http://2ality.com
On 01.04.2012, at 10:30, Dmitry Soshnikov<[email protected]>
wrote:
Oh, wait, just have read Crock's article on => functions. A Python's
style of passing manual `this'? That's interesting (why it's not
specified on the wiki? where Crockford took it from? did you discuss it
in a close ECMA meeting?). Inconsistent again with other functions.
So, let's see, overall we have .. 6 types of functions in JS, and all
have their own specific features. That's again interesting, if won't
cause confusion.
Dmitry
On Apr 1, 2012, at 1:13 AM, Dmitry Soshnikov wrote:
On Apr 1, 2012, at 12:34 AM, Axel Rauschmayer wrote:
Ah, good. But one can use the above (pseudo-)desugaring to predict
the behavior of arrow functions, right? That is, there is no
observable difference.
There is, again, the difference in terms of delegation to the
target's [[Construct]] in case of a bound function, see the spec
("bound" per ES5, of course, since, as Brendan notices, it's not just
a syntactic sugar, but a new special type of functions).
OK. Ignoring [[Construct]] and .prototype, any other differences?
Well, "ES5-bounds" also do not have `prototype' property, but delegate
to the target's `prototype'. However, yes, there is the (main)
difference in respect of supporting TCP (if I understand correctly,
since had no time to follow the complete thread) -- return and
break/continue jumps to the parent frame instead of working with the
function itself.
Lexical `this' is the only similar thing to bound functions, so we
should not call => functions as synonym to bound functions. You may
say, => function _as well as_ a bound captures `this' lexically, but
in contrast with it, it has other features. In my later analysis, I'll
specify them as a new type of functions -- AF (Arrow Function) -- in
addition to FE, FD, NFE, BF, etc., with many own features, but not just
a syntactic sugar -- neither for FE, nor for BF.
Dmitry
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
