@@iterator in arguments object

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

@@iterator in arguments object

Nathan Wall
I never fully understood why the arguments object couldn't be an array, and I know there is at least an attempted purge of the arguments object from the language with the addition of rest parameters.. But, for the transitional period, can the arguments object have an @@iterator property?  Please??

(I looked for it in the draft and didn't see it, but I might not have known where to look.)

Nathan    
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Rick Waldron



On Sat, Dec 22, 2012 at 4:57 PM, Nathan Wall <[hidden email]> wrote:
I never fully understood why the arguments object couldn't be an array, and I know there is at least an attempted purge of the arguments object from the language with the addition of rest parameters.. But, for the transitional period, can the arguments object have an @@iterator property?  Please??

Yes
 

(I looked for it in the draft and didn't see it, but I might not have known where to look.)

Likely because Allen had enough on his plate for this draft, but there is already a ticket based on a resolution from the last TC39 meetng: https://bugs.ecmascript.org/show_bug.cgi?id=1114


Rick


Nathan
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: @@iterator in arguments object

Nathan Wall
That's great news! Thank you!

Nathan
 

>> On Sat, Dec 22, 2012 at 4:57 PM, Nathan Wall
>> <[hidden email]<mailto:[hidden email]>> wrote:
>> I never fully understood why the arguments object couldn't be an array,
>> and I know there is at least an attempted purge of the arguments object
>> from the language with the addition of rest parameters.. But, for the
>> transitional period, can the arguments object have an @@iterator
>> property? Please??
>
> Yes
>
>
>> (I looked for it in the draft and didn't see it, but I might not have
>> known where to look.)
>
> Likely because Allen had enough on his plate for this draft, but there
> is already a ticket based on a resolution from the last TC39
> meetng: https://bugs.ecmascript.org/show_bug.cgi?id=1114 
>
>
> Rick    
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
In reply to this post by Rick Waldron

It's good this will be added (no reason not to) but I'll note that is much less of a requirement to even use the arguments object at all, especially iteration use cases that are pretty much filled by rest. In fact (almost?) the only place I've actually referenced the arguments object is to count the number of arguments to differentiate between deliberate undefined and a missing argument (and only for that use in order to match the behavior of how js engines treat the arguments to some string built-ins).


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Axel Rauschmayer
Parameter default values weren't good enough for this?


[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer

On 22.12.2012, at 23:57, Brandon Benvie <[hidden email]> wrote:

It's good this will be added (no reason not to) but I'll note that is much less of a requirement to even use the arguments object at all, especially iteration use cases that are pretty much filled by rest. In fact (almost?) the only place I've actually referenced the arguments object is to count the number of arguments to differentiate between deliberate undefined and a missing argument (and only for that use in order to match the behavior of how js engines treat the arguments to some string built-ins).

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
 You're right, defaults would take care of those few places reducing the need to reference the arguments object entirely. I think there may be one or two exceptions, like when there's no default value but an explicit `undefined` is coerced to "undefined" but a lack of the argument becomes an empty string. I guessable default value of the empty string may cover this but I have a nagging feeling there's some exception in one of the builtin methods that defies all attempts that don't rely on arguments.length, but I can't figure out what that method might be.

On Saturday, December 22, 2012, Axel Rauschmayer wrote:
Parameter default values weren't good enough for this?

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brendan Eich-3
Brandon Benvie wrote:
>  You're right, defaults would take care of those few places reducing
> the need to reference the arguments object entirely. I think there may
> be one or two exceptions, like when there's no default value but an
> explicit `undefined` is coerced to "undefined" but a lack of the
> argument becomes an empty string. I guessable default value of the
> empty string may cover this but I have a nagging feeling there's some
> exception in one of the builtin methods that defies all attempts that
> don't rely on arguments.length, but I can't figure out what that
> method might be.

If it exists, it's just bad precedent.

You could always use an explicit rest parameter as the only formal
parameter and still dispense with arguments in new code. So let's say
s/could/should/.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
Yeah good point, and you don't even need to dump all the named params. In light of this, I think its feasible to pronounce the arguments object in ES6 as vestigial and ready for retirement (except for all the legacy code of course). ES6 claims another victim: [object Arguments].

On Sunday, December 23, 2012, Brendan Eich wrote:
You could always use an explicit rest parameter as the only formal parameter and still dispense with arguments in new code.

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Allen Wirfs-Brock
In reply to this post by Brendan Eich-3

On Dec 23, 2012, at 9:38 AM, Brendan Eich wrote:

> Brandon Benvie wrote:
>> You're right, defaults would take care of those few places reducing the need to reference the arguments object entirely. I think there may be one or two exceptions, like when there's no default value but an explicit `undefined` is coerced to "undefined" but a lack of the argument becomes an empty string. I guessable default value of the empty string may cover this but I have a nagging feeling there's some exception in one of the builtin methods that defies all attempts that don't rely on arguments.length, but I can't figure out what that method might be.
>
> If it exists, it's just bad precedent.
>
> You could always use an explicit rest parameter as the only formal parameter and still dispense with arguments in new code. So let's say s/could/should/.
>

And you can then use destructuring assignment to parse out that rest parameter  into one or more signature patterns.

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Wes Garland
In reply to this post by Brandon Benvie
Arguments object is used here to fill the rest void, but also as an argument to apply (after converting into a real array) when writing wrapper functions; eg monkey patches, userspace profiling, etc.

Is there an ES6 way to use apply on rest params? If not, arguments must live on.

Sent from my iPhone

On 2012-12-23, at 12:48, Brandon Benvie <[hidden email]> wrote:

Yeah good point, and you don't even need to dump all the named params. In light of this, I think its feasible to pronounce the arguments object in ES6 as vestigial and ready for retirement (except for all the legacy code of course). ES6 claims another victim: [object Arguments].

On Sunday, December 23, 2012, Brendan Eich wrote:
You could always use an explicit rest parameter as the only formal parameter and still dispense with arguments in new code.

 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
Something like this?

var partial = (fn, ...args) => function(...newArgs){
  return fn.apply(this, args.concat(newArgs));
};


On Sun, Dec 23, 2012 at 2:26 PM, Wes Garland <[hidden email]> wrote:
Arguments object is used here to fill the rest void, but also as an argument to apply (after converting into a real array) when writing wrapper functions; eg monkey patches, userspace profiling, etc.

Is there an ES6 way to use apply on rest params? If not, arguments must live on.

Sent from my iPhone

On 2012-12-23, at 12:48, Brandon Benvie <[hidden email]> wrote:

Yeah good point, and you don't even need to dump all the named params. In light of this, I think its feasible to pronounce the arguments object in ES6 as vestigial and ready for retirement (except for all the legacy code of course). ES6 claims another victim: [object Arguments].

On Sunday, December 23, 2012, Brendan Eich wrote:
You could always use an explicit rest parameter as the only formal parameter and still dispense with arguments in new code.

 
_______________________________________________


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brendan Eich-3
In reply to this post by Wes Garland
Wes Garland wrote:
> Arguments object is used here to fill the rest void, but also as an
> argument to apply (after converting into a real array) when writing
> wrapper functions; eg monkey patches, userspace profiling, etc.
>
> Is there an ES6 way to use apply on rest params?

A rest parameter is a real Array instance. Function.prototype.apply
works on array instances. What's the problem?

/be

> If not, arguments must live on.
>
> Sent from my iPhone
>
> On 2012-12-23, at 12:48, Brandon Benvie <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> Yeah good point, and you don't even need to dump all the named
>> params. In light of this, I think its feasible to pronounce the
>> arguments object in ES6 as vestigial and ready for retirement (except
>> for all the legacy code of course). ES6 claims another victim:
>> [object Arguments].
>>
>> On Sunday, December 23, 2012, Brendan Eich wrote:
>>
>>     You could always use an explicit rest parameter as the only
>>     formal parameter and still dispense with arguments in new code.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Allen Wirfs-Brock
In reply to this post by Nathan Wall
As of ES5, apply doesn't require its 2nd arg to be a "real array". An arguments object works fine there.

Brendan Eich <[hidden email]> wrote:

>Wes Garland wrote:
>> Arguments object is used here to fill the rest void, but also as an
>> argument to apply (after converting into a real array) when writing
>> wrapper functions; eg monkey patches, userspace profiling, etc.
>>
>> Is there an ES6 way to use apply on rest params?
>
>A rest parameter is a real Array instance. Function.prototype.apply
>works on array instances. What's the problem?
>
>/be
>
>> If not, arguments must live on.
>>
>> Sent from my iPhone
>>
>> On 2012-12-23, at 12:48, Brandon Benvie <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>> Yeah good point, and you don't even need to dump all the named
>>> params. In light of this, I think its feasible to pronounce the
>>> arguments object in ES6 as vestigial and ready for retirement (except
>>> for all the legacy code of course). ES6 claims another victim:
>>> [object Arguments].
>>>
>>> On Sunday, December 23, 2012, Brendan Eich wrote:
>>>
>>>     You could always use an explicit rest parameter as the only
>>>     formal parameter and still dispense with arguments in new code.
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://mail.mozilla.org/listinfo/es-discuss
>_______________________________________________
>es-discuss mailing list
>[hidden email]
>https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
Here's one of the examples that was sticking out in my mind earlier that Brendan's solution takes care of. Array.prototype.reduce requires that if the initial value isn't provided then the first value of the array is the initial value.

Using rest:

    function reduce(callback, ...initial){
      var current, index;

      if (initial.length) {
        index = 0;
        current = initial[0];
      } else {
        index = 1;
        current = this[0];
      }
    
      ...etc...
    }


Using arguments.length:

    function reduce(callback, initial){
      var current, index;
      
      if (arguments.length > 1) {
        index = 0;
        current = initial;
      } else {
        index = 1;
        current = this[0];
      }
    
      ...etc...
    }



I guess using rest like that is not a bad way to solve it, though it's not saying what you mean but rather kind of hacking around the limitation. Either way, it's certainly possible to forgo using arguments to accomplish the goal.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Jason Orendorff
In reply to this post by Wes Garland
On Sun, Dec 23, 2012 at 1:26 PM, Wes Garland <[hidden email]> wrote:
Arguments object is used here to fill the rest void, but also as an argument to apply (after converting into a real array) when writing wrapper functions; eg monkey patches, userspace profiling, etc.

Is there an ES6 way to use apply on rest params? If not, arguments must live on.

There is something really nice. You can use the ... operator when calling a function. For example, if you're wrapping a function foo:

  _origFoo = foo;
  foo = function (a, b, ...rest) {
      // ... do something ...
      return _origFoo(a, b, ...rest);
  };

If you're wrapping a method it's not quite as nice, but:

  _origMethod = Bar.prototype.method;
  Bar.prototype.method = function (a, b, ...rest) {
      // ... do something ...
      return _origMethod.call(this, a, b, ...rest);
  };

-j


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Rick Waldron
In reply to this post by Brandon Benvie



On Sun, Dec 23, 2012 at 8:35 PM, Brandon Benvie <[hidden email]> wrote:
Here's one of the examples that was sticking out in my mind earlier that Brendan's solution takes care of. Array.prototype.reduce requires that if the initial value isn't provided then the first value of the array is the initial value.

Using rest:

    function reduce(callback, ...initial){
      var current, index;

      if (initial.length) {
        index = 0;
        current = initial[0];
      } else {
        index = 1;
        current = this[0];
      }
    
      ...etc...
    }


Using arguments.length:

    function reduce(callback, initial){
      var current, index;
      
      if (arguments.length > 1) {
        index = 0;
        current = initial;
      } else {
        index = 1;
        current = this[0];
      }
    
      ...etc...
    }



I guess using rest like that is not a bad way to solve it, though it's not saying what you mean but rather kind of hacking around the limitation. Either way, it's certainly possible to forgo using arguments to accomplish the goal.

In the case of reduce, the specification algorithm names an identifier in the formal parameter list: initialValue, so what is preventing your implementation from doing initial !== undefined?

Rick


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
Because initialValue can be a provided `undefined` in which case you would use that, as opposed to a missing value. The specification differentiates between a provided undefined and a lack of a parameter in a bunch of stdlib functions/methods.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Brandon Benvie
Er missing argument. The spec says "If an initialValue was provided in the call to reduce, ...". The fact that undefined is different from "not provided" is the reason you have to hack around with the argument count one way or another.


On Sun, Dec 23, 2012 at 9:25 PM, Brandon Benvie <[hidden email]> wrote:
Because initialValue can be a provided `undefined` in which case you would use that, as opposed to a missing value. The specification differentiates between a provided undefined and a lack of a parameter in a bunch of stdlib functions/methods.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Allen Wirfs-Brock
In reply to this post by Brandon Benvie

On Dec 23, 2012, at 5:35 PM, Brandon Benvie wrote:

> Here's one of the examples that was sticking out in my mind earlier that Brendan's solution takes care of. Array.prototype.reduce requires that if the initial value isn't provided then the first value of the array is the initial value.
>
> Using rest:
>
>     function reduce(callback, ...initial){
>       var current, index;
>
>       if (initial.length) {
>         index = 0;
>         current = initial[0];
>       } else {
>         index = 1;
>         current = this[0];
>       }
>    
>       ...etc...
>     }
>
>
> Using arguments.length:
>
>     function reduce(callback, initial){
>       var current, index;
>      
>       if (arguments.length > 1) {
>         index = 0;
>         current = initial;
>       } else {
>         index = 1;
>         current = this[0];
>       }
>    
>       ...etc...
>     }
>
>
>
> I guess using rest like that is not a bad way to solve it, though it's not saying what you mean but rather kind of hacking around the limitation. Either way, it's certainly possible to forgo using arguments to accomplish the goal.

the way I would express this example  is:

function reduce(callback, ...rest){
  var current, index;
  if (rest.length > 0) {
        index = 0;
        current = rest[0];
      } else {
        index = 1;
        current = this[0];
      }
  ...etc...
}

which seems to exactly express the intent

Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @@iterator in arguments object

Rick Waldron
In reply to this post by Brandon Benvie



On Sun, Dec 23, 2012 at 9:25 PM, Brandon Benvie <[hidden email]> wrote:
Because initialValue can be a provided `undefined` in which case you would use that, as opposed to a missing value. The specification differentiates between a provided undefined and a lack of a parameter in a bunch of stdlib functions/methods.

True enough: "is present", used in reduce, reduceRight, Object.create and then elsewhere in the abstract internals and then in different contexts.

Rick


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12