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

* Tab Atkins Jr. wrote:
>This is easy to do with CSSStyleDeclaration, because its keys are all
>ASCII (CSS properties are by convention restricted to the ASCII
>range).  However, CSSVariablesMap can also be returned by
>getComputedStyle (as the value of the "var" property on
>CSSStyleDeclaration), and its keys are arbitrary unicode characters.
>This *can* be sorted, but one of the reasons we made some of the
>choices we did with CSS Variables was specifically to avoid dealing
>with collation/etc issues.
>
>So, ideally, CSSVariablesMap could be defined in this case to return
>"unordered" keys.  Of course, that's not actually doable right now,
>because that just implies "implemented-defined order", which means we
>end up defining one of the impl-orders as the definitive order in a
>few years anyway.

>Would it be appropriate to define what Go does, and use it in IDL for
>Maps/Sets that we don't want to define an ordering for?  Is it
>something that JS would want to take up natively?

It seems to me that your proposal requires each implementation to define
an ordering of the variable names and randomising the iteration starting
point does not stop implementations to gravitate towards using the same
ordering, which would be as if that ordering had been defined initially,
only more painful. It would seem more ideal to define native `<` order
and be done with it. Certainly authors don't like dealing with behavior
that varies slightly across invocations or implementations or versions.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 31 August 2013 14:37:00 UTC