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 . <[email protected]> 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 <[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
