And that's where Class::StateMachine::Declarative shines: it's concise, and makes it easy for humans to apprehend the whole transitions set.
I realise now that objects, if they have several attributes, ARE multidimensional state machines anyway. My question was thus mostly about whether it is possible to unapply a Role; thinking that it could be useful some day.
Just one last quesiton: Is it possible to use Class::StateMachine in a Role?
| [reply] |
Class::StateMachine::Declarative is the result of my experience developing complex state machines, but for my current kind of problems that may be quite specific, I don't know how that could bend to the problems of other people.
I am still not completely happy with it, but it is true that the current iteration is much better than its predecessors.
Is it possible to use Class::StateMachine in a Role
No, because Class::StateMachine is a metaclass, it plays with the method resolution order (mro) to attain the specific state machine method resolution.
When I designed Class::StateMachine I have a hard time figuring how support the state machine while retaining the full perl object oriented semantics (specifically inheritance and multiple inheritance). But then, when I got to use it for practical matters, I discover that inheritance and state machines do not mix well.
Thinks like defining some states in one class, and others in a subclass, or refining them in the subclass is not a great idea.
It is ok to reuse (via inheritance or roles) the code that implements simple actions, but the state machine definition should be a coherent entity.
| [reply] |
I agree with you, that an intuitive API is the more important than implementation.
But do you have a real world example of a multidimensional state machine?
This "door" thing is just to shallow to justify the efforts and clarify advantages of different approaches.
Cheers Rolf
( addicted to the Perl Programming Language)
| [reply] |
Yes, a real common example is, on an event-based application, an object that has to do two (or more) things at the same time. For instance accessing a network service while tracking and external process or accessing a database.
You may be able to delegate most of the work needed to perform the subtasks to other objects (which would be unidimensional state machines). But there would be a point where you have to handle the interaction between them using a multidimensional state machine.
In any case, note that a multidimensional state machine can be converted into a unidimensional one if you flatten the state matrix using the cartesian product, or in practice, if you are able to organize the states in a tree (usually not all the multidimensional states may happen).
| [reply] |
Thanks! =)
> You may be able to delegate most of the work needed to perform the subtasks to other objects (which would be unidimensional state machines).
This would be my first choice.
The main object has attributes referencing the state objects.
> But there would be a point where you have to handle the interaction between them using a multidimensional state machine.
Thats where I would use "proxy"/wrapper methods in the class of the main object.
Cheers Rolf
( addicted to the Perl Programming Language)
| [reply] |
I don't have an example: it's just me playing with fire, and learning.
The closest example that i found is here. It's a video game character that can be turned into a Zombie, poisoned (which could make her stronger if she's a zombie), turned into a Chipmunk, an Angel (which turns it into a Dead-Angel if it's also a Zombie), break a leg, or any combination of the above.
Maybe i'll never need that in real life. But sometimes it's when you know that something is possible, that it gets you out of a complex situation elegantly.
And... i like learning and experimenting new ways.
| [reply] |