While I don't know the Moose guts, I remember that Moose was said to stay compatible to classical OO, mostly just adding syntactic sugar. ²
So I suppose that the normal search-path isn't manipulated in Moose.
This led me to 2 possibilities to implement this (rather JS-ish) requirement.
> by creating a new anonymous class with the object's previous class as superclass and with the roles applied,
Thats the first approach I thought about. But I'm worried about side effects. How transparent is this new class in the middle, does the instance still officially belong to the superclass?
FWIW my approach to implement the OP's state machine would certainly be to openly create sub-classes for each state with a common superclass defining the interface.
Like this state-changes could simply be realized with reblessings.
Different roles could still be applied to these "state"-classes, can't see any need to avoid inheritance here.
The other approach to have individual methods per instance could defining an attribute hash instance_methods which holds names => sub {} for each instance-method.
However calling this indiviual methods would imply the need to inherit equally named interface methods in the class to delegate the call.¹
Alternative an AUTOLOAD mechanism comes into mind, but these methods would have the lowest priority in the search path then.
BUT I can't see any need to implement a state machine this way.
IMHO the euphoria for mixins in Ruby was taken a bit to far.
Cheers Rolf
( addicted to the Perl Programming Language)
¹) such that $obj->my_meth() does something like $self->{instance_methods}{my_meth}->(@_).
²) plz correct me if I'm wrong!
In reply to Re^3: a State machine with Roles - possible? (class or instance)
by LanX
in thread a State machine with Roles - possible?
by mascip
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |