Le 13/06/2013 17:56, Kevin Gadd a écrit :
I don't really care about the precise language or semantics.
Maybe you should. In my opinion, that would certainly help having your
case better understood and heard.
I just don't want applications to break in the wild because an
Array.sort implementation's stability changes based on the number of
elements.
A stable sort is just a particular case of an unstable sort. So, if a
sort is "sometimes unstable", then it is "always unstable". The
impression of a stability for some cases is just a distraction.
It's also not like if "sort" was confusing like isNaN. "sort" does its job.
That feels like a much easier problem to solve than the problem of
some browsers being unstable and some being stable. This is absolutely
the sort of thing that would bite me as a JS dev and will bite every
person who uses my compiler to convert an application. Why would they
test with both small and large element counts?
They can also read the spec and learn they can't rely on sort stability
(second sentence of ES5 - 15.4.4.11 !). Specs aren't just for
implementors. As a web developer, I feel it's a time-consuming yet very
healthy exercise to read specs to avoid pain later down the road. I
wouldn't have said that for ES3, but ES5 is decently developer friendly,
especially http://es5.github.io/#x15.4.4.11 with links and all that.
If people are unsatisfied with the language sort function, maybe they
should pick a different sort function, implement one that fits their
need, why not.
They can even monkeypatch array#sort!
Why not try a stackoverflow sort [1][2]? Try with "stable sort" ;-)
David
[1] http://xkcd.com/1185/
[2] http://gkoberger.github.io/stacksort/
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
