Second arguments for Array.prototype.sort: map function

Mark S. Miller erights at
Tue Feb 28 09:34:30 PST 2012

On Tue, Feb 28, 2012 at 3:05 AM, Brendan Eich <brendan at> wrote:

> Yes, clear enough -- however adding new trailing arguments to an existing
> method is treacherous. It's likely calls in the wild pass a second argument
> by mistake. Less likely but still possible: an implementation has unwisely
> extended sort to have an optional second parameter already. This goes
> against the now-explicit NOTE in ES5:
> NOTE Implementations that add additional capabilities to the set of
> built-in functions are encouraged to do so by adding new functions rather
> than adding new parameters to existing functions.
> We could rule this out for the top five browser engines, but the
> possibility of extant code passing an extra actual parameter remains.

Why rule this out? IIRC, the rationale is that JS code is generally
encouraged to use "feature detection" style to attempt to detect presence
of new or optional functionality. The encouraged styles I've seen are
* if ('methodName' in obj)...
* if (obj.methodName)...
* if (typeof obj.methodName === 'function')...

I have not seen people "&&" these with a check of "obj.methodName.length
=== expectedArity". I would prefer to avoid encouraging such an additional
check -- especially as function arity has historically been unreliable as
an indicator of anything.

> Better to have a new sortWithTransform method if necessary.

If necessary, sure. This one doesn't seem so IMO.

> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list