Worth mentioning that D3.js, a popular visualization and SVG manipulating
library that I'm using heavily in my project, uses .call() to bind DOM
elements and invoke callbacks. Difficult to change that behavior without
overriding built-in function as you said, although I'm expecting something
cooler like: function (self = this) {}...... But never mind, thanks~
Yours,
Charles Weng
Andrea Giammarchi <andrea.giammar...@gmail.com>于2016年1月30日周六 00:56写道：
> Agreed there should be no changes in specs.
>
> However, you can solve with both utilities, one overwriting `call` (yak)
>
> ```js
> const boundCall = (f) => {f.call=(...a)=>f.apply(null,a);return f};
>
> function outer() {
> const inner = boundCall((_this) => {
> console.log(this.a, _this.b);
> });
> inner.call({b: 1});
> }
> outer.call({a: 2});
> ```
>
> and one creating Python like callbacks that will receive the `self` as
> first argument.
>
> ```js
> const snake = (f) => function snake(...a) {
> return f.apply(this, [this].concat(a));
> };
>
> const outer = snake((outerSelf) => {
> const inner = snake((innerSelf) => {
> console.log(outerSelf.a, innerSelf.b);
> });
> inner.call({b: 1});
> });
> outer.call({a: 2});
> ```
>
> As you can see there are plenty of different tricks you can use to make
> your custom Promise do whatever you but if you want a hint do not ever call
> a method `call` or `apply` ... it's the most misleading name you could
> think of, no matter what's the purpose, IMHO
>
> Regards
>
>
>
>
>
>
>
>
> On Fri, Jan 29, 2016 at 5:31 PM, ` Mystery . <mystery...@gmail.com> wrote:
>
>> 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 <andrea.giammar...@gmail.com>于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 . <mystery...@gmail.com>
>>> 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 <
>>>> jason.orendo...@gmail.com> wrote:
>>>>
>>>>> On Fri, Jan 29, 2016 at 8:14 AM, ` Mystery . <mystery...@gmail.com>
>>>>> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
