in reply to Re: input switch
in thread input switch

But there is no string manipulation nor checking in his second solution; whereas the first you are advocating does have string checking. String manipulation isn't exactly hideous either; a lot work has been put into making Perl blazing fast for that kind of task. (Number crunching on the other hand is hideous indeed.)

In other efficiency notes, remember that even though the name of the method in $obj->method() is known at compile time, Perl still has to look it up at run time. This is exactly the same amount of work as $obj->$anymethod() takes, so the if elsif route has to do as much work as the simpler method in addition to the string comparisons.

Note also that the best optimization method for Perl scripts is to try to offload as much work as possible into builtins. The if elsif does a lot of work in the script itself.

Lastly, I'd argue against the if elsif route simply because it makes for far harder to maintain code. The data driven method frees programmer time I can spend on getting more code written and/or bugfixed.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^2: input switch
by RatArsed (Monk) on Sep 09, 2002 at 08:16 UTC
    Right, the two main approaches are roughly:

    if...elsif... which requires string comparison before deciding which method it'll execute. (and of course, the string comparisons can have their order optimised)

    eval()ing, which needs to be wrapped up with a security check to ensure that someone doesn't try to do any "bad things" with it. Which means a series of string compares, to ensure it's a valid choice. Thus effectively becoming roughly the same thing...

    I'd argue this latter option is more difficult to maintain, as it could be argued that it'd be easier to miss out of the regexp.

    --
    RatArsed

      I don't see any eval in the code of my other node.

      Makeshifts last the longest.

        It's still doing a dispatch type of invocation. (so it's late bound) so at the lower levels, it's effectively the same as eval() to an extent -- you're still having to string comparison at runtime to check if the method exists, then invoking the late bound method, which naturally doesn't compile down as well as the early bound option which if...elsif... implies.

        --
        RatArsed