FiniteStateMachine's assumption about first property is non-standard
jorgensen.john at gmail.com
Tue Apr 17 06:03:33 GMT 2007
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
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
"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,
says that khtml and opera used to produce arbitrary enumeration
orders, but opera 9.10 enumerates properties in the order they were
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
More information about the samba-technical