| I agree. More generally, I would recommend to avoid any DSL. All DSLs are a downgrade over ruby language and there is a really narrow list of opportunities where they are an upgrade.
Everyone knows ruby when working on a Rails application. Everyone knows what a class, an instance is and what methods are.
Ruby is extendable, incredibly flexible and it doesn't need "special options" to be extended.
DSLs every time attempt to recreate the flexibility of ruby and require studying a new mini language.
When I'm in a dsl, I don't know if I can use an instance variable, if I need a method I don't know if I can have one.
More often then not, this question is not answered by the documentation and digging in the source code is needed. Most libraries with a DSL violate the first rule of a DSL: a DSL method should delegate to a normal object performing the operation, so that DSL API has also a corresponding normal ruby API. If you do this, your DSL is now extendable and replaceable, it can also be integrated into other libraries. As for state machines, the libraries recommended push toward objects violating the single responsibility principle. A state machine has already a super important responsibility: state-transitions. That's already a lot of work, if it has to trigger side effects, now it does way too much. Some alternatives: pub/sub! let the state machine be observable, whatever needs to do work when a certain state is reached, can do it when the event is published Alternatively as someone recommended below, service objects take care of: transition, persistance of the new state and side effects. If a new action is needed, a new service object can be written. The state machine can be used to validate the transition while the service object takes care of the rest. |