So I realized hole preservation is actually relevant in both array
structuring and destructuring. Array structuring and destructuring
ellipses forms are both specified in the draft spec to preserve holes.
Argument lists are merely array structuring patterns, and parameter
lists are merely array destructuring patterns, so to me, their syntax
and semantics should be the same. Thus, ellipses forms for argument
lists and parameter lists should be hole preserving as with array
structuring / destructuring. Take this example:
// rest has 98 holes
[a, b, ...rest] = [...Array(100)];
// extract into function form ->
// rest should still have 98 holes, not 98 undefined's
(function(a, b, ...rest){})(...Array(100));
On Fri, Sep 30, 2011 at 8:41 AM, Sean Eagan <[email protected]> wrote:
> On Thu, Sep 29, 2011 at 2:53 PM, Allen Wirfs-Brock
> <[email protected]> wrote:
>> It seems highly desirable that we preserve the existing semantics of
>> arguments
>
> I agree, for backward compatability.
>
>> and that:
>> function foo(...args) {
>> assert(length.arguments === length.args};
>> for (let i in arguments) assert(arguments.hasOwnProperty(i) ===
>> args.hasOwnProperty(i) && arguments[i] === args[i]);
>> }
>
> I disagree, rest parameters are intended as an eventual permanent
> replacement for `arguments`, and thus it is more important to make
> them have the correct and consistent with array literal spread element
> hole preservation behavior, than consistency with what will be the
> legacy `arguments` to aid a one time migration to rest parameters. To
> illustrate the problems I see with filling holes in rest parameters,
> assume we are working with a holey array:
>
> let holeyArray = [];
> holeyArray[99] = true;
>
> and some code which uses it:
>
> let spreadTarget = [a, ...holeyArray, b]; // 99 holes
> holeyArray.forEach(expensiveOperation); // 1 iteration
>
> at some point we decide to abstract this code into functions:
>
> function f(...arr) {
> return [a, b, ...arr];
> }
> function g(...arr) {
> arr.forEach(foo); // holes now filled leading to extra iterations
> }
> ...
> let spreadTarget = f(...holeyArray); // 99 unwanted `undefined`s now
> g(...holeyArray); // 100 iterations now
>
>
>> regardless of how foo was called. In other words, baz(...bar) and
>> baz.apply(undefined,bar) should always produce the same effect.
>
> I agree since one form is not intended to replace the other. The
> effect IMHO should be that if baz uses `arguments`, holes are not
> preserved for backward compatability, but if baz has upgraded to rest
> parameters, then holes are preserved.
>
>
> Also, I think not filling holes can be optimized since the `undefined`
> values don't need to be added to the rest parameter argument.
>
> Thanks,
> Sean Eagan
>
Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
