in reply to Really Long if/elsif/else blocks

I wanted tight control over the order of tests

use an array or arrayref to store your list of tests.

Many of my tests involve function calls, not just eq tests

a dispatcher can use a coderef (anonymous sub) to determine if the dispatch is to be used.

Intermediate results from earlier tests are saved in 'my' variables and used by later tests.

use a state variable of some sort that you pass to each dispatch selector. This would then hold your intermediate values.

Then again, I tend to oversimplify things.

--MidLifeXis

Replies are listed 'Best First'.
Re^2: Really Long if/elsif/else blocks
by throop (Chaplain) on May 30, 2008 at 19:32 UTC
    Thanks. But I'm still puzzled. The array, the dispatcher, the state variables. I'm having a really hard time imagining how that would all come together, especially in a way that would be as easy to follow as the original code. Here's a simplified, but still tangled, if/elsif/else block. Could anybody take a gander at what the code would look like with the array, the dispatcher and the state variables?
    Read more... (696 Bytes)
[reply]
[d/l]

      I'll give it a shot....

      Read more... (1036 Bytes)

      What is nice, is that you can take this to the next level, and break some of your related tests into modules, and write the above in a manner that would allow those modules to register new checks (put $checks setup into registerCheck() and the loop into runChecks).

      registerCheck(test => sub {...}, action => sub {...});

      [download]

      I have used this method for testing to see if lists of documents and attributes meet certain criteria, saving state for the entire run, and reporting not only on individual items, but the results of the entire run. The logic looks very similar to what I have above.

      --MidLifeXis

[reply]
[d/l]
[select]
        respect. I like this idea.
[reply]

In Section Seekers of Perl Wisdom