Mark S. Miller
erights at google.com
Mon Feb 13 22:31:28 PST 2012
There are many benefits to determinism. E started with non-deterministic
iteration order, which opens a covert channel hazard. I initially changed
to deterministic order merely to plug this leak. Having done so, I found it
had many software engineering benefits. For example, it becomes much easier
to write regression tests and to reproduce bugs by re-execution. In my
implementation, it also had a minor additional space and time cost. Tyler's
Waterken tables show that even the minor runtime costs I was paying were
Let's not introduce yet another source of non-determinism for the sake of
an unmeasured efficiency. Let's measure, and if the cost turns out to be
high after all, then let's reconsider determinism.
Premature optimization is....
On Mon, Feb 13, 2012 at 10:22 PM, Erik Arvidsson
<erik.arvidsson at gmail.com>wrote:
> On Mon, Feb 13, 2012 at 21:25, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
> > Unless TC39 specifies otherwise, the enumeration order of Map and Set
> > will be arbitrary, it will certainly be inconsistent across browsers,
> > and it will most likely even include a random component per Map/Set
> > object.
> > It is very hard to see how any code could depend on a particular
> > implementation's enumeration order if it is randomized.
> I think we should be careful not to specify the iteration order and we
> should make sure that the first two implementations intentionally do
> not agree on the ordering.
> This is our one time chance to get this right and we don't want to
> paint us into another corner with Map/Set iteration order.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss