I'm using Moose
(specifically MooseX::Declare
) to create an iterator object, Iter
which has a next
method that advances state and returns 0
or 1
as required for use in a while
statement. The problem I'm running into is that depending on the existence of one of the construction parameters, next
needs to perform two very different sets of operations. The way I see it I have five options:
- if ... then in
next
method - subclass
- hash dispatch
- symbol table manipulation
- put methods in different modules and load required one at construction time
Number 1 is just amateur.
Number 2 is, I suppose, the proper OOP way of doing things. I have no objections to doing it that way but seems a little bit overkill simply to override a single method.
I've often used Number 3 in the past when working procedurally or pseudo-functionally and it's what I'm doing now.
Number 4 is, as we all know, fraught with peril and I know nothing about Moose Guts to want to start messing around when unnecessary.
The last item, number 5 seems to me to be the most sensible (and Perlish) but like Number 2, is a little too much work. I'm really wondering if there's a fifth way I haven't considered such as hooking into the metaclass or perhaps a MooseX
module that is reasonably mature.
Pass your 'next' subref into the constructor and save it in an attribute:
With the 'execute_method' handler provided by the native attribute 'Code' trait, you can call the 'next' method as a normal method and it will find the subref body in the attribute.
If you want to pre-define the subref body/ies and decide at construction time which version to use, you could set the value of 'next' in a builder sub according to other conditions of the object:
Another option is to dynamically apply a role: