Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

question regarding using Switch.pm in production use

by jfroebe (Parson)
on May 02, 2005 at 15:46 UTC ( [id://453292]=perlquestion: print w/replies, xml ) Need Help??

jfroebe has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I'm curious as to why, in some circles, that use of Switch and other source filters are taboo for use in production. Can someone explain why someone would avoid or use source filters?

thanks!

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Replies are listed 'Best First'.
Re: question regarding using Switch.pm in production use
by kvale (Monsignor) on May 02, 2005 at 16:01 UTC
    The main problem with source filters is that they must parse Perl code in order to transform it, and Perl code is very hard to parse. Perl has a lot of context sensitivity and parsing it involves more that a straight lexing-parsing data flow; there is a subtle interaction between the lexing and the parsing that even has probabilistic aspects to it.

    This is what folks mean when they say that only perl can parse Perl :) Thus source filters are playing with code they do not fully understand, and could be considered dangerous.

    If you wnat to use Switch.pm in production code, I'd recommend coding stanards to keep the conditional for the cases reasonbly simple, and test always.

    -Mark

Re: question regarding using Switch.pm in production use
by Roy Johnson (Monsignor) on May 02, 2005 at 16:10 UTC
    Re^3: Assignable Subroutines has a fair bit of discussion on the (de)merits of source filters. Ovid's response is particularly salient.

    If I were using source filters, I would be very careful to write easy-to-parse Perl.


    Caution: Contents may have been coded under pressure.
      If I were using source filters, I would be very careful to write easy-to-parse Perl.

      The trouble is, even that's not good enough. Someone posted a snippet on p5p in this thread, showing how the current incarnation of Switch gets tripped up by thinking it's in a string instead of code, or vice versa.

      The trouble was that the snippet's only sin was that the word 'case' appeared in a comment... Something as arbitrary as that just gives me the willies.

      - another intruder with the mooring in the heart of the Perl

        I've had similar experiences quite a while ago, just after having discovered Perl. Before then I'd mainly been playing around with C, so discovering there was a way to emulate Switch made me quite a happy camper. Initially it all worked fine, and then things just started going funky. Quite dazzled, I finally ended up replacing the entire Switch by a huge(and i do mean huge, a couple hundred possibilities) if-elsif-elsif-else contraption which worked exactly the way I wanted it to. Never really looked back after that. If something doesn't work exactly the way it is supposed to work, especially when there's a perfectly good alternative, why take the risk?

        To stray from the topic for a moment, I can't think of a reason why it would be impossible to implement a form of switch in pure Perl though. It'd likely be a lot slower than if-elseif-else, but it'd make for a nice intellectual challenge ;-)

        Obviously someone already rose to the challenge, as I could have predicted had I turned my brain up a notch for just a second there. Seems that someone also happened to post just before I did...

        Remember rule one...
        The trouble is, even that's not good enough. Someone posted a snippet on p5p in this thread, showing how the current incarnation of Switch gets tripped up by thinking it's in a string instead of code, or vice versa.
        I don't think that's much of a problem. It's not that your code is different each time it's run. Your code is fixed, and each time it's run, it's the same input to the source filter. It's simple to test see whether the output is correct, or garbage. If the latter, fix your input, or fix your filter.
Re: question regarding using Switch.pm in production use
by ikegami (Patriarch) on May 02, 2005 at 16:05 UTC
    Source filters need to parse Perl code. That's very hard to do correctly for a given version of Perl, and it's even harder to do for all versions of Perl. There's even a saying concerning this: "Only perl can parse Perl." For example, I notice Switch uses Text::Balanced, which is falls apart when given split(//, $var). (Use $var =~ /(.)/g instead.) I've heard of other bugs in Text::Balanced.

Re: question regarding using Switch.pm in production use
by brian_d_foy (Abbot) on May 03, 2005 at 03:20 UTC

    Source filters are bad because you can't look at the code and tell what it is going to do. The filter turns other things, including something that might look like a comment, into behavior. That's a maintenance nightmare.

    The difficulty in parsing Perl is a red herring. Even if Perl was easy to parse source filter based code is hard to maintain.

    --
    brian d foy <brian@stonehenge.com>
Re: question regarding using Switch.pm in production use
by DrHyde (Prior) on May 03, 2005 at 09:12 UTC
    What irritates me most about them is that your bugs move. If you have an error in your code inside or after a Switch for instance, the line numbers spat out in the error and diagnostic messages will be wrong, because they are the line numbers in the code after the source filter has diddled with it.

      Of course, a properly written source filter will insert #line statements, to keep the error messages in sync with the original file. Once you stack a second source filter on top of that, things become hairy, as then, that second source filter needs to understand #line hints as well, and parse them accordingly. Which is unlikely to be correct. I'm not sure if Filter::Simple implements that, but I found #line very handy when dealing with code generated from templates.

      As Perl allows anonymous code structures, I tend to try to avoid code generation from templates and try to use as much anonymous code structures as possible, because then I get the Perl syntax check at initial compile time and not at template compile time, which may be in mid-flight already.

        Ooh, I learnt something new! Where is #line documented so I can learn how it works?
Re: question regarding using Switch.pm in production use
by doom (Deacon) on May 03, 2005 at 16:45 UTC
    My big complaint about "Switch" is that when you try to trace your code with the perldebugger you end up looking at Damian Conway code instead.

    I used to think that using "Switch" was a cool thing to do, at least for relatively light-duty code (whether used in "production" or not), but it really only provides a small syntactic advantage, and makes it a lot harder to understand what's going on.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://453292]
Approved by Old_Gray_Bear
Front-paged by monkfan
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2024-03-29 12:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found