in reply to Re: How to create multipurpose lvalue sub such as CGI::param ?
in thread How to create multipurpose lvalue sub such as CGI::param ?

That's just cruel!

  • Comment on Re^2: How to create multipurpose lvalue sub such as CGI::param ?

Replies are listed 'Best First'.
Re^3: How to create multipurpose lvalue sub such as CGI::param ?
by dragonchild (Archbishop) on Mar 22, 2008 at 18:46 UTC
    First off, that made me laugh. :-)

    But, it also serves a few very important purposes.

    1. It's opensource for a reason. Leverage that.
    2. param() is one of the most complicated methods in CGI, for a reason - it does a gazillion things. Replicating that isn't simple and it shouldn't be seen as simple.
    3. Lincoln's code is actually quite good. It's the problemspace that sucks. Newbies could do with a worse teacher of style and readability.
    4. Client bugs suck. There's a ton of code in there to deal with browser incompatibilities. Newbies need to be smacked in the face about that, and often.

    There is method to my cruelty.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Lincoln's code is actually quite good.

      Except for self_or_default() which is clever but not clear in terms of interface and that hand-rolled autoloading mess (private methods are in the code segment and public methods are in the data segment) which makes debugging nearly impossible for almost everything you want.

        You know as well as I do that both those complaints (valid as they may be) were done for equally valid reasons. For the edification of the reader ...
        • self_or_default() was a design decision that, in hindsight, probably should've been done differently. Breaking backwards compatibility in the core module and providing a wrapper would probably have been a saner solution.
        • The hand-rolled autoloading mess is something you won't get Lincoln to apologize for. Until the advent of mod_perl and similar persistent interpreters, anything that could be done to speed up CGI.pm was considered a good thing.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?