[mp1mp2mp3]

On why not to use "transition :somestate => :otherstate", it would be because then other optional arguments might conflict with the state names. For example, if the `transition` method takes an optional argument of `given:` then a state machine could not have state called `given`. In fact, no optional arguments could be added in a backwards compatible way.

The states could be passed positionally but, imo, the increased verbosity helps readability rather than hinders it.

Your example code seems not really thought through. If I were to implement that, then I would write code that looked like this: `my_thing.state = :some_action; assert my_thing.state == :some_new_state`. Now we're spending company money discussing whether the state machine code you decided to write by yourself has a reasonable interface.

I've used aasm for years and it's just fine. If someone suggested we just implement a non-trivial state machine with our own homegrown solution, I would push back. Trust the community's experience and just pull in the well-established library. There seems to me a certain hubris in deciding that the rest of the world has settled on an overly complex solution when, if they had just thought for a moment, it should just be a 'switch` statement.

[vidarh]

Then you explicitly pass the transitions as a hash, or provide other methods for those specific options, but part of my point was that adding so many options in the first place is part of the problem of that API. It's trying to do way too much at the same time, and the result is you're ending up with really excessive code.

My example code was a quick and dirty example; instead of state= you could use "event" or whatever name you prefer. You're having the discussion about API whether you have it explicitly or have it by having the discussion about pulling in those gems.

And the point was the verbosity of it, not the details. If you need "a solution" for a state machine, odds are your state machine is too big and convoluted and ought to be decomposed, because to me at least their examples obfuscates the state machine they're defining in a way that is a huge red flag.

I definitely would not trust "the community's" experience on this - it's by no means "the rest of the world" that has settled on this, but a tiny subset. Thankfully I've never had to deal with code using either of these gems "in the wild" in 19 years of Ruby development.

Having looked at the source of the state_machine gem, I'm now even less inclined to want it anywhere near my code. It's grossly over-engineered. A quick look at aasm makes it look slightly saner, but it's still grossly invasive and huge amounts of code.

[vidarh]

Too late to edit, but see also: https://news.ycombinator.com/item?id=39087098 where I give a more fleshed example of something more similar that I'd be happier with, and which you'll notice is a lot closer to aasm than the linked gem. Compared to the state_machines gem, aasm I have mostly nitpicks over the syntax of and most of my issue is that the implementation is way more complex than it needs to be.

By all means, use what you're familiar with - aasm is by far the better choice if you've first made the investment.