Permalink
Browse files

Update description.

  • Loading branch information...
1 parent 67d57c6 commit 8ad6fe99a5283d6594402b9c4ee630a6cd323c6b @soveran committed Mar 30, 2012
Showing with 1 addition and 1 deletion.
  1. +1 −1 micromachine.gemspec
View
@@ -1,6 +1,6 @@
Gem::Specification.new do |s|
s.name = 'micromachine'
- s.version = '1.0.1'
+ s.version = '1.0.2'
s.summary = %{Minimal Finite State Machine.}
s.description = %Q{There are many finite state machine implementations for Ruby, and they all provide a nice DSL for declaring events, exceptions, callbacks, and all kinds of niceties in general.\n\nBut if all you want is a finite state machine, look no further: this has less than 50 lines of code and provides everything a finite state machine must have, and nothing more.}
s.author = "Michel Martens"

3 comments on commit 8ad6fe9

Hey soveran,

I couldn't message you in github because it said you didn't have an email set. I'm wondering if you have any thoughts on what the advantages/disadvantages are of using a composition instead of mixin implementation.

Owner

soveran replied Apr 2, 2012

Hey @andrewroth,

It's a great question. The usual approach of other FSM implementations
is to provide a DSL. The problem is that a DSL brings with it a lot of
code that has to cope with the fact that the definition happens at the
class level, while the execution happens at the instance level. That
forces the implementation of the DSL to recreate parts of Ruby. (You
will notice how the abstraction leaks when you see constructions like
:if => :bar_is_true, etc.) Also, and because of that, there is a
noticeable performance penalty. I went ahead and coded an example
using both state_machine and micromachine:

https://gist.github.com/228f7365c17596896285

In that example, both definitions are compatible at the API level, but
one performs much better than the other. The definition of Vehicle
with state_machine is shorter, but that's because I added helper
methods that state_machine already defines. (It means the code exists
in both cases, only that in the case of state_machine, it is already
defined.)

Something that is not worrying for most people, but it is for me, is
the total LOC in a project. In this case, we are talking about 37 LOC
in micromachine versus 3342 in state_machine. This may sound
ridiculous, but if I copied and pasted those 3342 lines of code in one
of my objects, it would become very hard to deal with. That's the
exact picture I have in mind when I discuss lines of codes in
libraries.

Another issue is that in general, whenever there's the possibility of
using composition, it's preferable. I makes the overall implementation
simpler, because you are always dealing with small objects. By using
mixins, you are growing your objects with instance level methods, and
you are forcing method calls to look up in yet another layer.

I'm sorry if my answer is not what you were looking for, feel free to
ask me again if I missed the point.

By the way, I just configured an email in my account, thanks :-)

Thanks for writing this up. I see what you're saying, but isn't the performance concerns not that important in a web app? The state machine won't be performing thousands of operations, just once in a while when a post comes in that triggers the state to change.

Please sign in to comment.