prepend FiniteMachine instance methods with a prefix/postfix like "__"

[dmgr]

There might be a reason to define events like "success" or "fail". For "fail" event that error appear:

FiniteMachine::AlreadyDefinedError: You tried to define an event named "fail", however this would generate "instance" method "fail", which is already defined by FiniteMachine

[piotrmurach]

Thanks for using the library!

Currently the state machine follows the pattern whereby the event names are directly converted to dynamic methods. As much as there is no problem storing :fail state, the mothod definition is a bit trickier. However, we could do something along the lines:

fsm = FiniteMachine.define do
  events prefix: 'car' {
    event :fail, :red => :green
  }
end
fsm.car_fail # => transitions from :red to :green

What do you think? Could you provide me example use case of your state machine?

[piotrmurach]

@dmgr Any thoughts?

[dmgr]

Hi @peter-murach.
I'd rather thought to prepend/append internal API methods of FiniteMachine. So internally the instance method:

    def fail

would be:

    def _fail_

to have less name clashes.

[piotrmurach]

Hi @dmgr Thanks for your feedback.

There is no internal representation of event as such. The event sole reason is the ability to trigger transition and it is just a name that gets converted to a method. There are no intermediate steps and hence the implementation is relatively simple. Going forward, I would probably investigate why the fail method cannot be generated as I don't define it anywhere inside the codebase hence probably get some false positives asking the finite machine object for it's implemented methods.

[wbreeze]

fail is a method in the Kernel available on any and every object. In order to add a fail event, the finite machine would have to generate a method other than fail, and one would no longer be able to use the very direct method call format on the finite machine in order to effect a transition. (Which is what Piotr said.)

Stick with the very straightforward method call syntax and make clear in the documentation that event names cannot collide with the name of any method of the class on which the finite machine is defined, including methods inherited from Object and Kernel.

[dmgr]

Hmm, so maybe a better idea will be to have an option to tell StateMachine to not generate direct event methods. We will be able to call events using #trigger(event_name) method and we wouldn't need to worry if a method implemented in other modules like Kernel/Object name already exists or not.

#46