On 05/05/13 8:31 PM, Carla F. Griggio wrote:
I will keep experimenting with this during the next weeks, and specially try to compare the pros and cons with regular event handling.
I've always been curious to see how state machine transitions would map to Announcements/event handling.
Something cool about this approach is that the same widget could change its interactive behaviour on the fly by just attaching a different interaction state machine to it :)
Changing the state machine is called "subtype migration" in Shlaer-Mellor parlance. It seems to get tricky when the supertype also has a state machine.
Also, I'm doing this for programming user interface interactions, but it could be useful for anything that can be modelled with a state pattern. Is there something similar out there already working? I was so eager to try this that I didn't look for related existing projects.
The PostgreSQL Client [1] (a native Smalltalk client connection to a Postgres server) uses an internal state machine to drive the client/server connection. It was built with the Shlaer-Mellor method [2] concepts in mind. There was an accompanying state machine diagram drawn with the Connectors [3] tool (the link from SqueakMap is long dead, but I could try to dig up a copy).
The implementation is very awkward around where the public API to make SQL queries interacts with the underlying state machine inside the PGConnection object. There's a loop that continues until a "good" state is reached. Then the result is gathered from the connection object. Since the code making the SQL query is not event-driven, nor is it part of the same state-machine architecture of the postgres client, the result is the awkward loop.
I'd really like to see more examples of state machine usage. [1] http://www.squeaksource.com/PostgresV2.html [2] http://en.wikipedia.org/wiki/Shlaer–Mellor_method [3] http://wiki.squeak.org/squeak/1773
