On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock <[email protected]> wrote:
> as it currently stands, a function is allowed to use both:
>
> function f(a,b,c,...rest) {
> g(...arguments);
> h(...rest);
> }
Rest parameters are capable of anything arguments objects are and
more, so what use case would there ever be for using both? Your
example can be rewritten using only rest parameters as either:
function f(a,b,c,...rest) {
g(...[a,b,c,...rest]);
h(...rest);
}
or
function f(...arguments) {
[,,,...rest] = arguments;
g(...arguments);
h(...rest);
}
Rest parameters are intended to deprecate `arguments`, if both are
allowed simultaneously then this deprecation will be much harder to
accomplish. I would even go so far as to disallow the use of
`arguments` altogether in "extended code", to encourage the use of
rest parameters and accelerate the deprecation of `arguments`.
> In a high perf implementation, the arguments to a function call will
> typically be passed as a dense sequence of values on the processor stack.
> Not as an actual array object. Such a sequence normally does not include any
> way to encode the existence of "holes" so a new mechanism would have to be
> added by implementors. Probably a distinguished value. Such mechanisms
> typically carry a cost. For example, such a distinguished internal marker
> value must never be exposed to JS code as the value of formal parameter. So,
> the callee might have to scrub each argument position and replace each hole
> with undefined. It already has to do something like that for default value
> parameters (based on the size of the argument list) but now it would have to
> do it for every parameter.
Hopefully I'm not getting in way over my head here, but I did some
digging in spider monkey code, and here's what I found:
* There is already a distinguished value for array holes [1].
* The Function.prototype.apply code [1] loops over the passed argument
array [2], copying each element over to the argv structure of the
callee, explicity converting holes to undefined [3]. These
conversions could instead be done by the callee only for indexes
corresponding to non-rest formal parameters and indexes which may be
accessed from an arguments object, which as I argue above, should
never coexist with a rest parameter. Indexes corresponding to a rest
parameter would not be coverted to holes, and thus hole preservation
would be acheived.
[1]
http://dxr.mozilla.org/mozilla/mozilla-central/js/src/jsfun.cpp.html#l1866[2]
http://dxr.mozilla.org/mozilla/mozilla-central/js/src/jsfun.cpp.html#l1913[3]
http://dxr.mozilla.org/mozilla/mozilla-central/js/src/jsarray.cpp.html#l441[4]
http://dxr.mozilla.org/mozilla/mozilla-central/js/src/jsval.h.html#l259
Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
