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.