in reply to Re^4: a State machine with Roles - possible? (class or instance)
in thread a State machine with Roles - possible?

I'm neither a Moose nor a Ruby expert, but I think with this Ruby code one can instantiate multiple objects each with individual states.

But since Moose roles operate on classes you'll be restricted on a singleton class, i.e. just one object (resp. all objects with the same state.)

But again theoretical thoughts, maybe better if I refrain from this subject.

But thanks for bringing it up, I learned a lot.

Cheers Rolf

( addicted to the Perl Programming Language)

PS: I just remember that I once had a similar requirement which I solved with a state attribute.

So calling $self->{state}{method}() solved it for me and I was able to have multidimensional states per object.

Thats very similar to the already proposed proxy-methods.

  • Comment on Re^5: a State machine with Roles - possible? (class or instance)

Replies are listed 'Best First'.
Re^6: a State machine with Roles - possible? (class or instance)
by james2vegas (Chaplain) on May 30, 2013 at 20:41 UTC
    While it is true that only one class (package) is created for every unique combination of class and role to apply, that doesn't limit those objects to be singletons, they would each have their own state, shared with the roles applies to them.
[reply]
      I'm not sure if you are getting my point.

      Let's say I want to model a house with 100 doors.

      The Ruby code allows to call 100 times new() from class "Door" to create 100 door objects with independent states, because the methods of the mixins belong to the objects.

      The shown Moose code OTOH needs 100 packages achieve this, cause all objects of such a package share the same roles. This doesn't sound very handy or scalable.

      And I couldn't see any code to generate such classes, hence we have to manually name them Door1, Door2, ...Door100.

      Plz correct me if I'm wrong.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

    • UPDATE 01 Jun 2013

      oops, I just realized that you already explained the mechanism behind apply_all_roles further up this thread. Sorry, I wasn't aware we are talking about the same approach.

[reply]

        I don't know how Ruby mixins works, and i'm not sure how Moose/Moo implement it exactly, but i know that it's possible to have each Door be in a different state. Because that is what apply_all_roles_to($object, @roles) is for: it does not apply to the whole class, but only to one object.

        I have no idea about the scalability. I think that Salva made a good point: if it gets that complicated, i'll probably want to re-think my design.

[reply]

In Section Seekers of Perl Wisdom