[+tjclose] 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 unnecessary.
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 <[email protected]>wrote: > On Mon, Feb 13, 2012 at 21:25, Jason Orendorff > <[email protected]> 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. > > > -- > erik > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
