FiniteStateMachine's assumption about first property is non-standard

[John Jorgensen]

I've noticed a Minor issue in swat as a consequence of a class
exercise (I'm trying to semi-automatically generate graphviz code for
drawing pictures of Swat finite state machines).

The implementation of start states in  qx.util.fsm.FiniteStateMachine
depends on an assumption which isn't warranted by the JavaScript
definition, though the assumption is probably fulfilled by most
browsers you care about.

Looking for the Start states for my graphs, I found the comment in
qx.util.fsm.FiniteStateMachine reading:

 "The starting state is defined as the first state added
   to the finite state machine."

The implementation of this specification in
qx.util.fsm.FiniteStateMachine.start() assumes that the first property
added to an Object (in this case the _states object) will always be
listed first in an enumeration of that object's properties.  That is
certainly true for all the browsers I've tried, and competitive
pressure between the browsers may have made it true for all of them (a
3-year-old article google turned up,
http://blog.persistent.info/2004/08/javascript-associative-arrays.html,
says that khtml and opera used to produce arbitrary enumeration
orders, but opera 9.10 enumerates properties in the order they were
added).

According to David Flanagan's "Javascript: The Definitive Guide", 5th
edition, p. 108, though, no enumeration order is guaranteed. I'm not
experienced in reading standardese, but section 12.6.4 of the ECMA-262
specification of ECMAScript says that the "mechanics of enumerating
the properties ... is implementation dependent. The order of
enumeration is defined by the object."

So, strictly speaking, FiniteStateMachine.js should save the start
state under a separate name, rather than relying on it always being
enumerated first. But you might decide that's too persnickety to worry
about.