**THIS POST IS NOW BEING MAINTAINED AT:http://thefreakparade.com/2008/07/evaluating-expressions-at-runtime-in-net-c/
**THIS POST IS NOW BEING MAINTAINED AT:http://thefreakparade.com/2008/07/evaluating-expressions-at-runtime-in-net-c/
THIS POST HAS BEEN MOVED TO: http://thefreakparade.com/2008/05/scripting-coding-writing-dsls-in-net-via-boo/
Boo is an interesting, extremely flexible CLR language with an “open compiler architecture” – which means that you can easily extend its compiler to accommodate your needs. I bought a Manning Early Access Program (unfinished, unedited, and rough around the edges) book by Ayende Rahien called Building Domain Specific Languages in Boo that, despite the writing style, which conveys an accent and is so informal that it almost borders on the insane, has already proven quite useful. The book relies on an open source library, also by Ayende Rahien (of Rhino Mocks fame) called Rhino DSL. The library itself is small, simple and effective. In addition to DSL’s, Boo (which is a statically typed, compiled language) has an optional interpreter and seems like it could be effectively used as a runtime scripting language, in addition of course to being a full blown .NET language you could write your business objects or UI in.
Anyway, below are a few resources I have come across while researching this topic in support of creating a state machine DSL referenced in my previous post:
Scripting With Boo
Binsor : Castle IOC container configuration using Boo DSL from Ayende
DSL Support
Early Access Book: Building DSLs in Boo (Ayende)
Specter Framework – writing executable object specs using a Boo DSL
An interesting example of TDD using Specter
Article on DSL’s using BOO by Ayende
A list of open source apps written in boo
Martin Fowler is writing a book on DSL’s also
Using Boo as an embedded scripting language
Visual Studio Integration via BooLangStudio
SimpleStateMachine project using a Boo DSL for configuration
I have posted a CodePlex project here that implements a simple, customizable State Machine & miniature runtime. The point of this project was to replace Windows Workflow Foundation in one of our applications as the state machine engine. Windows Workflow foundation is a powerful, robust technology but turns out to be unsupportable overkill if all you are really after is defining and coordinating state transitions in your application. Plus, it can be rather difficult to unit test, even more difficult to version and extend once an application is deployed, and requires all sorts of baggage in the form of database infrastructure and GAC requirements, etc.
Anyway, this library does nothing else besides let you define a set of events, states, and transitions between states when triggered by events, and optionally allows for user defined actions to fire during the initialization or finalization of any or all states.
As for representing the actual state machines there are a few options: A visual designer such as WF provides. The WF designer itself is awful for representing state machines, even simple ones, as it was designed to suit sequential workflows as well and the two kinds of diagrams have different needs. It might be possible to create a visual designer that did the job well, but it would be a big task. Another option is to configure state machines in code using an object model or fluent interface. This would have worked, but it ends up looking pretty ugly after a while and you can’t change your state machines without deploying updated assemblies.
The approach I settled on was to use a DSL, using Boo and Rhino DSL, as described by Ayende Rahien in his (unfinished) book on the subject. The State Machine language itself was inspired by Martin Fowler, who appears also to be writing a book about DSL’s.
An example state machine definition looks like the sample below. It isn’t as snazzy and colorful as the visual designer version you get with WF, but in practice it is much more practical.
workflow "Telephone Call"
trigger @CallDialed
trigger @HungUp
trigger @CallConnected
trigger @LeftMessage
trigger @PlacedOnHold
trigger @TakenOffHold
trigger @PhoneHurledAgainstWall
state @OffHook:
when @CallDialed >> @Ringing
state @Ringing:
when @HungUp >> @OffHook
when @CallConnected >> @Connected
state @Connected:
when @LeftMessage >> @OffHook
when @HungUp >> @OffHook
when @PlacedOnHold >> @OnHold
state @OnHold:
when @TakenOffHold >> @Connected
when @HungUp >> @OffHook
when @PhoneHurledAgainstWall >> @PhoneDestroyed
state @PhoneDestroyed
