On Tue, Oct 4, 2011 at 4:09 PM, Sean Eagan <[email protected]> wrote: > 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
The sources got mangled, should be: [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
