in reply to Re^6: No braces
in thread No braces

Damian's Switch.pm relies on source filtering, which means that unless it can parse Perl perfectly (ha ha!), you'll get bugs in portions of code that having nothing to do with switches just because you included use Switch; in your code. So it shouldn't be used in any practical code.
I don't agree with that. It's an argument against editor filters for colouring text - they either have to be perfect for any text thrown at them, or you have to suffer the consequences. A source filter is fundamentally different. There you apply a filter to a program. And then you run your tests. If the filter works, you're done. Otherwise, you tune your filter and/or your program until it works. (But usually, the filter will work the first time).

Abigail

Replies are listed 'Best First'.
Re: Re: No braces
by hardburn (Abbot) on Feb 11, 2004 at 16:26 UTC

    Editors don't have to be perfect at coloring text, because the worst that can happen is that the colors are wrong when you view the source--it's annoying, but I can live with it. In the case of Switch.pm, anything other than parsing code exactly the way perl does is unaccaptable, because anything less will cause bugs, often in areas which are unrelated to the use of a switch. There are a few source filters which don't have to be perfect because they're doing very simple things (Acme::Bleach comes to mind), but Switch.pm isn't one of them.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      In the case of Switch.pm, anything other than parsing code exactly the way perl does is unaccaptable, because anything less will cause bugs, often in areas which are unrelated to the use of a switch.
      That's like saying you can't make typos when editing, because they cause bugs. And you are implying those bugs can't be found before they product is released. If Switch.pm parses something incorrectly, it's very likely to produce uncompilable code. Perhaps you deliver code without even attempting to compile, I sure don't. In the few cases it doesn't produce uncompilable code, it'll produce code that is wrong - and your test suite is going to catch it. (If it doesn't produce code that's wrong, the code is correct, so it's not a problem). If you don't want to trust your test suite, you can always visually inspect the results of the source filter, to check whether it substituted only the code you wanted to be substituted, and all of it.

      The essence is that you write a particular program, and apply a filter to it. And that program isn't going to change from run to run. It's fixed. It's not input. Switch.pm might not parse Perl correctly, but that's ok because you can catch the abnormalities in time.

      Abigail

        You're just creating more work for yourself by using Switch.pm. If it screws up the parsing, you now have to change code (which may be completely unrelated to the code that actually uses a switch statement) just to work around bugs in Switch.pm. That's a lot more work for something that is little more than syntax sugar and is easily replaced with a multitude of common Perl idioms. Even if you make all the workarounds in the current version of Switch.pm, new versions may introduce brand new bugs for you to work around.

        The correct solution is to avoid Switch.pm in the first place for serious code.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated