Yes, the example you show is sufficient for most scenarios. However the situation I came across is more complex: The custom Promise class I implemented uses .call() to bind the same "this" scope object across different .then() tasks, so they can exchange variables just simply by storing them in "this". Of course it will work if I just pass that environment object as a parameter, but it would require a lot of work to modify other callbacks that does not use "this" of the outer function. Perhaps I should stick to storing a "self" variable instead of introducing so many changes. ;)
Andrea Giammarchi <[email protected]>于2016年1月30日周六 00:07写道： > Sorry Charles, I'm not sure I understand. Would this work? > > ```js > function outer() { > const inner = (_this) => { > console.log(this.b, _this.a); > }; > inner({b: 1}); > } > outer.call({a: 2}); > ``` > > that should produce what you expect already, right? I think it's > misleading to use `.call` with a bound/arrow function, as it's misleading > to have two different `this` in params or body. > > Just my pov > > > On Fri, Jan 29, 2016 at 4:37 PM, ` Mystery . <[email protected]> wrote: > >> >> Hi, >> >> @Andrea Giammarchi >> Sorry, perhaps I didn't express myself clearly. I use .call() to manually >> bind the context "this" to a function, and yes, the last one is exactly >> what I need, accessing both contexts (inner and outer) which I couldn't >> manage without using an additional variable, as described in the following >> snippet: >> >> ```js >> function outer() { >> const inner = function (_this = this) { >> console.log(this.b, _this.a); >> }; >> inner.call({b: 1}); >> } >> outer.call({a: 2}); >> ``` >> >> @Jason Orendorff >> I see. If JavaScript is going to support calling class functions with >> class members as default parameters, it has to parse the default values >> with the given "this" context at calling. Perhaps that's also the reason >> why the most language does not support this feature, like C++ and >> Python..... but it's JavaScript :) >> >> Thanks guys for the patient explanation. >> >> Yours, >> Charles Weng >> >> On Fri, Jan 29, 2016 at 10:41 PM Jason Orendorff < >> [email protected]> wrote: >> >>> On Fri, Jan 29, 2016 at 8:14 AM, ` Mystery . <[email protected]> >>> wrote: >>> > IMHO I don't think the default parameters should be evaluated within >>> the >>> > context of the function being called, at least not while it's outside >>> of >>> > function body's region...... Is there a specific reason to do that, or >>> it's >>> > just a design preference? >>> >>> Sure, there is a reason: it's about how defaults are used. >>> >>> Most defaults are probably constants or empty objects. Those don't >>> need to refer to any variables at all, so we can set them aside. >>> >>> Of the rest, I suspect *most* refer to previous parameters: >>> >>> function send(sender, recip, message, onBehalfOf=sender) { ... } >>> >>> or the `this` for the current method call: >>> >>> class MyArray { >>> ... >>> slice(start=0, stop=this.length) { ... } >>> } >>> >>> The only way to support these is to put the arguments in scope. >>> >>> (Another reason is consistency. This is how `var` initializers already >>> work, and have always worked: initializers are in the scope of the >>> bindings being initialized, and can use the values of previously >>> initialized bindings on the same line of code.) >>> >>> -j >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
