Thinking out loud which may or may not have to do w/ OP...
I can't help but think of (C++-like) copy constructor and assignment op overload methods, given one instance of the class, to be used to return a spanking new instance of the same class. (That's what BrowserUk was trying to show, which is illustrated in the last "pipeline" statement.)
Had i been unfamiliar w/ C++, i would myself have been checking for the reference type in the function to create an class instance. Now, writing two separate functions (in Perl) to create class instance does not seem bothersome despite the Perl code that i have seen so far. (BTW, i have yet to write an OO Perl module.)
Getting back to the problem... If using jwest's idea, states could be stored in an array reference, in a hash, w/ file names (or file/IO objects, as appropriate) as the keys. Missing states could be omitted altogether or undef'd. (Needless to say this array ref. value could just as well be a hash ref.)
Personally, i would try BrowerUK's idea first (complete w/ appropriate class cloning/copying method separate from class constructor) as it is simpler in approach. If really necessary, use a hash like above to keep a list of processes applied.
If that works, then i would try the one-big-encapsulating-object idea. ("If the former works, why..." you say? Well, that's up to you, BazB.) Or, if skipping the simpler idea, i would search CPAN and Internet for prior art before embarking upon the latter approach for it seems crude (based on the desrciption alone).
In reply to Re: Re: Tracking processing by returning objects?
by parv
in thread Tracking processing by returning objects?
by BazB
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |