Array#sort() implementations not interoperable
bruant.d at gmail.com
Thu Jun 13 09:50:49 PDT 2013
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
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 - 220.127.116.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/#x18.104.22.168 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 ? Try with "stable sort" ;-)
More information about the es-discuss