On Mon, Oct 3, 2011 at 11:35 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote: > >> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson >> <erik.arvids...@gmail.com> wrote: >>> But Function.prototype.apply doesn't preserve holes. >> >> Function.prototype.apply doesn't preserve holes for the the >> `arguments` object, but rest parameters aren't yet standardized, and >> are intended to replace the `arguments` object, so they could, and in >> my view, should preserve holes for both Function.prototype.apply and >> foo(...args) activations, at least if array structuring and >> destructuring preserve holes as currently specified in the ES.next >> draft spec. > > > In general, a call site doesn't have any knowledge of format of the formal > parameter list of the callee and the callee doesn't have any knowledge of how > the caller constructed the argument list. So the caller and callee argument > semantics can't be interdependent.
I'm not suggesting the semantics of the caller and callee be interdependent, just that the semantics of a function are dependent on whether it has yet upgraded from `arguments` to rest parameters. > Also, we probably need to factor in the fact that most current > implementations probably don't have a mechanism for passing holes in an > argument and that adding such a mechanism might be a deep and expensive > change. Would the cost to implementors really be worth the benefit to JS > developers? I have no implementation experience, but I don't see what cost you are referring to. It seems likely to me that there would be a performance benefit since implementations don't need to add undefined values to the rest parameter, and since user code can skip holes if desired such as via ES5 Array extras. Thanks, Sean Eagan _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
