in reply to Re^4: Can't locate object method- Issue
in thread Can't locate object method- Issue

This sounds like horribly bad design.

You haven't told us what problem you are trying to solve by this approach, but from my perspective, it looks as if your approach would be far better served by an object A that has another object B, which gets removed or replaced by a third object C if its behavirour needs to change:

A -> B

# Change behaviour:

A -> C

[download]

Maybe, B and C can implement some roles, but the interface of A should remain identical and delegate to its worker, B or C.

Replies are listed 'Best First'.
Re^6: Can't locate object method- Issue
by jdporter (Paladin) on Sep 29, 2013 at 02:30 UTC

    Well, that's a classic OO pattern (delegation), but IMHO having whole objects just to contain a subset of behavior is overkill. Roles are packages of behavior explicitly.

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]

      Certainly, but at least to my superficial understanding of Roles, you are not supposed to change your mind after the fact. Once you've mixed together some Roles in a class, you are not supposed to change the class further, or even worse, make changes on a per-object basis.

      If you need to dynamically change the class hierarchy/composition, or need to change the behaviour on a per-object basis, in my opinion, you should look at using objects that delegate to other objects instead.

      Meta: I came back to this comment due to the (maybe continued) discussion of the topic in 1056122.

[reply]
        ...not supposed to change your mind...

        But this is Perl. ;-) We can re-bless. We can mess with the class inheritance tree. We should be able to mess with roles, too.

        I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]

In Section Seekers of Perl Wisdom