W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Unordered setsmaps, for when ordering is hard/expensive/unwanted?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Sep 2013 12:44:35 -0700
Message-ID: <CAAWBYDD5Dr2+q9AMe1GdaJVA7_fVHGFrxdc4wQaK5JM_4utL9g@mail.gmail.com>
To: Brendan Eich <brendan@secure.meer.net>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Sep 2, 2013 at 12:25 PM, Brendan Eich <brendan@secure.meer.net> wrote:
> No, but thanks for your patience going through why it's hard to require a
> canonical order. We'll have to do one or both of:
> * Leave things unspecified.
> * Add the random starting index _a la_ Go, as Tab suggests.
> In either case, we would hope that the problem Bjoern cites doesn't come to
> pass (that one implementation's order becomes a de-facto standard). Without
> evidence I have a hard time believing either bullet-point affects the
> likelihood of that problem arising.

Well, we know from experience that the first one is a no-go - we
always end up with compat pain, sometimes getting bad enough to force
a de facto order to become a de jure one.

The second one at least has a chance - in a lot of cases, authors
depending on a particular order will be broken fast.  (In particular,
anyone depending on things being at a particular index will be broken
immediately.  Anyone depending on things near each other remaining
near will be broken an amount of time relative to the distance between
them and the size of the rest of the set.)  Since an author can't work
around the breakage except by removing their order-dependence (or
explicitly handling it by shifting the values into a Set/Map of their
own, manually).

And as an added bonus, if you've removed your order dependency, then
if we *do* end up with the whole thing being wasted effort, us
removing the random start won't hurt you either.  ^_^  (Of course, you
may have come to depend on the random start for some reason. C'est la

Received on Monday, 2 September 2013 19:45:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC