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

On Sat, Aug 31, 2013 at 7:36 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * 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.

I believe that randomizing the starting point on each iteration makes
the pressure to use the same orderings much weaker.  Whether this is
weak enough to justify doing this is the question I brought to the
group.

~TJ

Received on Saturday, 31 August 2013 21:09:15 UTC