Allen Wirfs-Brock wrote:
We made a decision about Function length and default parameters in the
past and I don't see a compelling reason to change that decision now.
I'm ok with that, so (IEEE754 nod): +0.
The plan of record doesn't impact the node use case that Kevin
identified as they specify that 4 non-optional parameters are required
and we aren't making any changes in the counting of non-optional
parameters for length purposes. Passing callback functions with
optional parameters in those corresponding argument positions wouldn't
make sense because the call backs are always called using a fixed set
of arguments. See http://www.wirfs-brock.com/allen/posts/166 for a
discussion of the hazards of mixing callee optional and caller
optional function signatures.
Good points.
For example, Array.prototype.slice has a legacy length of 2 but its
signature would be best expressed as:
Array.prototype.slice(start, end=this.length)
which using the ES6 function length rules would have a length of 1.
A common use of slice is to clone an array-like as a real array:
[].slice.call(arguments) is calling with zero actual parameters. So one
could argue that slice's signature is actually
Array.prototype.slice(start=0, end=this.length).
But we can farble it somehow to preserve compatibility, or break if
anyone really thinks we should try to roll those dice (I don't see much
upside).
push has a legacy length of 1 while it signature would be best
expressed as:
Array.prototype.push (...items)
which ES6 says has a length of 0.
By far the most common use-case is to push one value, so for legacy's
sake, if not clarity's sake:
Array.prototype.push(value, ...rest)
Among other things, differences between the generated length property
values of ES code functions (note this is a non-configurable,
non-writable property) and required specified values make it harder to
self-host implementations of built-ins using ES code. I would like to
change the specified lengths of all the built-ins to match the length
that would be generated if their signature was expressed using default
value initializers and rest parameters. I believe that we made some
adjustments to the length of a few of the built-ins in ES5 (or
implementations adjusted their implementations to match the spec) so I
suspect that additional changes to the length of a few built-ins for
ES6 would have little impact.
I'm not sure, but see above for some minor doubts about your preferred
signatures, which might dodge some compat-break risk.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
