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: Brendan Eich <brendan@secure.meer.net>
Date: Mon, 02 Sep 2013 12:25:38 -0700
Message-ID: <5224E632.7040408@secure.meer.net>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: public-script-coord@w3.org
> Boris Zbarsky <mailto:bzbarsky@MIT.EDU>
> September 2, 2013 12:16 PM
> On 9/2/13 12:50 PM, Brendan Eich wrote:
>> The proposal is to enumerate properties in a canonical order
>
> Which order?

That's the question, but I hope I'm not out of line asking us to 
consider defining one. "No, too constraining on implementations and 
performance" is a fine answer.
>
>> "insertion order" by some deterministic algorithm that inserts 
>> properties into the
>> object in question (gCS's result, e.g.)
>
> There is no such algorithm right now: determination of computed style 
> is not done via any particular serial algorithm.
>
> In actual UAs at least in Gecko computed values for properties are 
> computed in a non-deterministic order (specifically, we compute them 
> lazily, so will compute them when someone asks) and in Servo I am 
> hoping we'll be able to compute them in parallel, so _definitely_ not 
> in any particular order.
>
> Is your proposal to disallow such implementation strategies?

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.

/be
Received on Monday, 2 September 2013 19:26:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC