Re: Using 'this' in default parameters

[Jason Orendorff]

On Fri, Jan 29, 2016 at 8:14 AM, ` Mystery .  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

Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

Hi,

I have prepared a strawman for the `?.` operator:

https://github.com/claudepache/es-optional-chaining/ 


If there is interest in that proposal, I'm looking for a champion from TC39.

Regards,

—Claude___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Using 'this' in default parameters

[Bergi]

` Mystery . wrote:

During the development of an ES6 web application, I came across a situation
where I wanted to bind 'this' of the outer function to a parameter of an
inner function


Use an arrow function for that:
```
function outer() {
const inner = (_this = this) => {
console.log(_this.a); // 1
}
inner.call({});
}
outer.call({a: 1});


In the latest Firefox, the above script prints 'undefined'. This seems
pretty counter-intuitive, and it also fails when I try to pass 'this.a' as
default value for the parameter of the inner function. I wonder if this is
an intended behavior? Thanks in advance.


Yes, it is intended, and pretty intuitive - default initialisers are 
evaluated in the scope of the called function, at the call - they're not 
values that are computed at the time of the definition of the function.


Regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Using 'this' in default parameters

[` Mystery .]

Hi,

Thanks for the replies. I'm aware of the arrow functions, but the reason I
don't use them here is that I wish to bind a custom context to the inner
function (i.e. preserve the "this" passed while calling the inner function,
like a custom context for promise callbacks for example) and use some
variables in the outer function's context as well (might be a class
method). Guess I should fallback to old "saving this to a variable"
technique in this situation.

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?

Yours,
Charles Weng

On Fri, Jan 29, 2016 at 9:27 PM Bergi  wrote:

> ` Mystery . wrote:
> > During the development of an ES6 web application, I came across a
> situation
> > where I wanted to bind 'this' of the outer function to a parameter of an
> > inner function
>
> Use an arrow function for that:
> ```
> function outer() {
>  const inner = (_this = this) => {
>  console.log(_this.a); // 1
>  }
>  inner.call({});
> }
> outer.call({a: 1});
>
> > In the latest Firefox, the above script prints 'undefined'. This seems
> > pretty counter-intuitive, and it also fails when I try to pass 'this.a'
> as
> > default value for the parameter of the inner function. I wonder if this
> is
> > an intended behavior? Thanks in advance.
>
> Yes, it is intended, and pretty intuitive - default initialisers are
> evaluated in the scope of the called function, at the call - they're not
> values that are computed at the time of the definition of the function.
>
> Regards,
>   Bergi
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Using 'this' in default parameters

[Andrea Giammarchi]

Hi Charles, I think this discussion is not really appropriate for this ML
but I'd like to point out you have already all possible solutions.

For instance, you don't need to bond at all for your case since you use
`.call` already. Please be sure you understand what `.call` does because
it's kinda pointless to use both `.call` and `.bind` or bound variables.

Example:

```js
function outer() {
  function inner() {
console.log(this.a);
  }
  inner.call({});
}
outer.call({a: 1});
```

If you need to bring in the default `this` arrow function does exactly that
and it will be pointless to `.call` an arrow function with a different
context.

```js
function outer() {
  const inner = () => {
console.log(this.a);
  };
  inner.call({}); // or just inner();
}
outer.call({a: 1});
```

If you'd like to create an inner function with a different context you can
use `.bind` which has been in core for quite a while and its purpose is
exactly that one.

```js
function outer() {
  const inner = function () {
console.log(this.a);
  }.bind({});
  inner();
}
outer.call({a: 1});
```

As you can see the last thing we need is yet another way to bind something
in the language ... but of course, if you really want to use the `var self
= this` pattern you are free to do that, no need to change specifications
though.

Eventually, what you might want is a hsortcut for function like `->`
instead of `=>` could be ... but that's a whole different story.

Best Regards



On Fri, Jan 29, 2016 at 3:14 PM, ` Mystery .  wrote:

> Hi,
>
> Thanks for the replies. I'm aware of the arrow functions, but the reason I
> don't use them here is that I wish to bind a custom context to the inner
> function (i.e. preserve the "this" passed while calling the inner function,
> like a custom context for promise callbacks for example) and use some
> variables in the outer function's context as well (might be a class
> method). Guess I should fallback to old "saving this to a variable"
> technique in this situation.
>
> 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?
>
> Yours,
> Charles Weng
>
> On Fri, Jan 29, 2016 at 9:27 PM Bergi  wrote:
>
>> ` Mystery . wrote:
>> > During the development of an ES6 web application, I came across a
>> situation
>> > where I wanted to bind 'this' of the outer function to a parameter of an
>> > inner function
>>
>> Use an arrow function for that:
>> ```
>> function outer() {
>>  const inner = (_this = this) => {
>>  console.log(_this.a); // 1
>>  }
>>  inner.call({});
>> }
>> outer.call({a: 1});
>>
>> > In the latest Firefox, the above script prints 'undefined'. This seems
>> > pretty counter-intuitive, and it also fails when I try to pass 'this.a'
>> as
>> > default value for the parameter of the inner function. I wonder if this
>> is
>> > an intended behavior? Thanks in advance.
>>
>> Yes, it is intended, and pretty intuitive - default initialisers are
>> evaluated in the scope of the called function, at the call - they're not
>> values that are computed at the time of the definition of the function.
>>
>> Regards,
>>   Bergi
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Using 'this' in default parameters

[` Mystery .]

Hi all,

During the development of an ES6 web application, I came across a situation
where I wanted to bind 'this' of the outer function to a parameter of an
inner function, here is a quick snippet demonstrated what I'm trying to do:

function outer() {
  function inner(_this = this) {
console.log(_this.a);
  }
  inner.call({});
}
outer.call({a: 1});

In the latest Firefox, the above script prints 'undefined'. This seems
pretty counter-intuitive, and it also fails when I try to pass 'this.a' as
default value for the parameter of the inner function. I wonder if this is
an intended behavior? Thanks in advance.

Yours,
Charles Weng
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Using 'this' in default parameters

[` Mystery .]

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 
wrote:

> On Fri, Jan 29, 2016 at 8:14 AM, ` Mystery .  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

Re: Using 'this' in default parameters

[` Mystery .]

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 于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 .  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 . 
>>> 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

Re: Using 'this' in default parameters

[Andrea Giammarchi]

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 .  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 . 
>> 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

Re: Using 'this' in default parameters

[Andrea Giammarchi]

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 .  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 于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 . 
>> 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 . 
 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

Re: Using 'this' in default parameters

[` Mystery .]

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 于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 .  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 于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 . 
>>> 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 . 
> 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.
>
> 

Re: Additional methods for Objects (like Arrays)

[Dmitry Soshnikov]

On Friday, January 29, 2016, Rick Waldron  wrote:

>
>
> On Fri, Jan 29, 2016 at 6:08 PM Kaustubh Karkare <
> kaustubh.kark...@gmail.com
> > wrote:
>
>> I have recently come to feel the need for Object.map, which is like
>> Array.map,
>> except that it receive keys instead of indices.
>>
>> Object.prototype.map = function(mapFn, context) {
>>   return Object.keys(this)
>> .reduce(function(result, key) {
>>   result[key] = mapFn.call(context, this[key], key, this);
>>   return result;
>> }, {});
>> };
>>
>> Without this, I frequently do the exact same thing as the above manually,
>> which leads to unnecessary code duplication.
>>
>> Given that, it might make sense to match other methods from
>> Array.prototype
>>
>> Object.map
>> Object.filter
>> Object.every
>> Object.some
>> Object.reduce
>> Object.find
>> Object.findKey // like Array.findIndex
>>
>
>
> Are these necessary given the introduction of Object.values() and
> Object.entries()? https://github.com/tc39/proposal-object-values-entries
>
>
I think what Kaustubh is proposing is that the result is a transformed
object/map, not an array. See the reduce method in his implementation.

Dmitry



> Rick
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Additional methods for Objects (like Arrays)

[Dmitry Soshnikov]

Yeah, some languages have this functionality available for maps, e.g.
Erlang http://erlang.org/doc/man/maps.html#map-2. Might be a good addition,
although considering `Map` instead of `Object` is worth as well. (although,
when we were discussing of adding `Map.prototype.map/filter`, it was
decided that it's better to add them on iterators).

Dmitry

On Fri, Jan 29, 2016 at 3:07 PM, Kaustubh Karkare <
kaustubh.kark...@gmail.com> wrote:

> I have recently come to feel the need for Object.map, which is like
> Array.map,
> except that it receive keys instead of indices.
>
> Object.prototype.map = function(mapFn, context) {
>   return Object.keys(this)
> .reduce(function(result, key) {
>   result[key] = mapFn.call(context, this[key], key, this);
>   return result;
> }, {});
> };
>
> Without this, I frequently do the exact same thing as the above manually,
> which leads to unnecessary code duplication.
>
> Given that, it might make sense to match other methods from Array.prototype
>
> Object.map
> Object.filter
> Object.every
> Object.some
> Object.reduce
> Object.find
> Object.findKey // like Array.findIndex
>
> Note that wherever applicable, the ordering is non-deterministic.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Additional methods for Objects (like Arrays)

[Dmitry Soshnikov]

On Fri, Jan 29, 2016 at 3:07 PM, Kaustubh Karkare <
kaustubh.kark...@gmail.com> wrote:

> I have recently come to feel the need for Object.map, which is like
> Array.map,
> except that it receive keys instead of indices.
>
> Object.prototype.map = function(mapFn, context) {
>   return Object.keys(this)
> .reduce(function(result, key) {
>   result[key] = mapFn.call(context, this[key], key, this);
>   return result;
> }, {});
> };
>
>
Also a potential issue of placing it on `Object.prototype` is that other
things will inherit it, including unrelated (like strings, regexps,
functions, etc). By this reason seems iterator methods `values`, `keys`,
and `entries` weren't added in ES6 to `Object.prototype`.

Dmitry



> Without this, I frequently do the exact same thing as the above manually,
> which leads to unnecessary code duplication.
>
> Given that, it might make sense to match other methods from Array.prototype
>
> Object.map
> Object.filter
> Object.every
> Object.some
> Object.reduce
> Object.find
> Object.findKey // like Array.findIndex
>
> Note that wherever applicable, the ordering is non-deterministic.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Additional methods for Objects (like Arrays)

[Alican Çubukçuoğlu]

> Are these necessary given the introduction of Object.values() and
Object.entries()?

`Object.entries()` works. `Object.p.map()` would be shorter to write,
easier to read and more compatible with functions already written for
`Array.p.map()`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Additional methods for Objects (like Arrays)

[Kaustubh Karkare]

I have recently come to feel the need for Object.map, which is like
Array.map,
except that it receive keys instead of indices.

Object.prototype.map = function(mapFn, context) {
  return Object.keys(this)
.reduce(function(result, key) {
  result[key] = mapFn.call(context, this[key], key, this);
  return result;
}, {});
};

Without this, I frequently do the exact same thing as the above manually,
which leads to unnecessary code duplication.

Given that, it might make sense to match other methods from Array.prototype

Object.map
Object.filter
Object.every
Object.some
Object.reduce
Object.find
Object.findKey // like Array.findIndex

Note that wherever applicable, the ordering is non-deterministic.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Additional methods for Objects (like Arrays)

[Rick Waldron]

On Fri, Jan 29, 2016 at 6:08 PM Kaustubh Karkare 
wrote:

> I have recently come to feel the need for Object.map, which is like
> Array.map,
> except that it receive keys instead of indices.
>
> Object.prototype.map = function(mapFn, context) {
>   return Object.keys(this)
> .reduce(function(result, key) {
>   result[key] = mapFn.call(context, this[key], key, this);
>   return result;
> }, {});
> };
>
> Without this, I frequently do the exact same thing as the above manually,
> which leads to unnecessary code duplication.
>
> Given that, it might make sense to match other methods from Array.prototype
>
> Object.map
> Object.filter
> Object.every
> Object.some
> Object.reduce
> Object.find
> Object.findKey // like Array.findIndex
>


Are these necessary given the introduction of Object.values() and
Object.entries()? https://github.com/tc39/proposal-object-values-entries

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Additional methods for Objects (like Arrays)

[段垚]

在 2016/1/30 7:07, Kaustubh Karkare 写道:
I have recently come to feel the need for Object.map, which is like 
Array.map,

except that it receive keys instead of indices.

Object.prototype.map = function(mapFn, context) {
  return Object.keys(this)
.reduce(function(result, key) {
  result[key] = mapFn.call(context, this[key], key, this);
  return result;
}, {});
};

Without this, I frequently do the exact same thing as the above manually,
which leads to unnecessary code duplication.

Given that, it might make sense to match other methods from 
Array.prototype


Object.map
Object.filter
Object.every
Object.some
Object.reduce
Object.find
Object.findKey // like Array.findIndex

Note that wherever applicable, the ordering is non-deterministic.

I'd rather add them as static methods of Object, e.g.

var result = Object.map(obj, function(value, key) { ... });

Because when I use an object as a map, I usually create it without 
prototype (Object.create(null)),

to avoid unintentional access of properties on Object.prototype.





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Shared memory and atomics

[Lars Hansen]

The shared memory and atomics spec entered Stage 2 at the TC39 meeting this
week, and the spec repository was moved to
https://github.com/tc39/ecmascript_sharedmem.

For the sake of the historical record I'm hoping to keep discussion
(outside the TC39 meetings) confined to Issues on the tracker for that
repository as much as possible, and I ask those of you that have an
interest in the feature to make sure you are watching the repository.

Over the next few months the work on this feature will focus on refining
and solidifying the API and addressing remaining issues around the memory
model.  All issues that have to be resolved before the spec can advance are
marked with the "Stage 3" milestone.  Some experimentation with additional
features will continue in parallel with the refinement work.

--lars
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss