State machine builder: looking for feedback

I've implemented a small internal "domain-specific language" (or rather
a fluent interface) for defining finite state machines in JavaScript.
The description of a simple machine looks like this

var Machine = FSM.build(function(fsm) { with (fsm) {
onUnexpectedEvent(function() { ... });

state('start', 'initial')
.event('go')
.goesTo('middle')
.doing(function() { ... })
.doing('phew')
.event('run')
.goesTo('finish')
.onExiting(function() { ... });

state('middle')
.onUnexpectedEvent(function() { ... })
.onEntering(function() { ... })
.event('back')
.goesTo('start')
.onlyIf(function() { return true_or_false })
.event('go')
.goesTo('finish');

state('finish', 'final');
}});

Here's how such a machine is inserted into the prototype chain of an
object that acts as the context for the machine.

function TestMachine() {}
// amend TestMachine.prototype here all the way you want
TestMachine.prototype.phew = function() { ... };
TestMachine.prototype = new Machine(TestMachine.prototype);

var m = new TestMachine();
m.isStart(); //-> true
m.go();
m.isMiddle(); //-> true

The script itself has no external dependencies, however, the tests and
example use js-spec and Prototoype.

The script itself and a package with tests and example are at

http://schuerig.de/michael/blog/inde.../30/jsfsm-022/
http://schuerig.de/michael/blog/inde...avascript-fsm/


I'd appreciate constructive criticism, here and on my blog. There are
three topics I'm particularly interested in

- (more) elegant ways of managing what 'this' means
- how to minimize the size of closures
- memory leaks. Are there any? How would I track them down and fix them?


Michael

--
Michael Schuerig
mailto:michael (AT) schuerig (DOT) de
http://www.schuerig.de/michael/

Michael Schuerig wrote:
[schnipp]

Ach, das "de." am Anfang hat doch eine Bedeutung. Tschuldigung.

Michael

--
Michael Schuerig
mailto:michael (AT) schuerig (DOT) de
http://www.schuerig.de/michael/