http://qs321.pair.com?node_id=145557


in reply to RFC CGI.pm refactoring

I think the discussion goes to a wrong direction.

Wait! I'd like to say why I think so before you kill me. :-)

The documentation for the Common Gateway Interface does not mention the ability of producing a specified _document_ syntax or structure upon browser requests but how to handle browser requests and how to reply to them by giving declarations _about_ the document to be returned, not about its specific content.

Therefore the question is, how all these nice and very usefullfull HTML and now xhtml spitting out functions made it into a module called CGI.pm. Well, I like the way it is, but I dislike the idea of seeing CGI.pm updated twice or thrice a year because of new document syntax, which is not troubling the CGI as an interface at all, except additional mime-types to be declared, well.

To get to the point: _I think_ all functions and methods that do not belong _by definition of the interface_ into CGI.pm should be "deported" to another modul or should be replaced by another modul as there are now plenty of them.

To keep compatibility with older versions, upon 'use CGI;' an additional option might be passed, for example 'use CGI(-noTags);' indicating that I want the plain interface communication handled by CGI.pm and nothing more. If that option is omitted CGI.pm should load all that baggage and overload it is carrying then in other modules as CGI::HTML or CGI::SGML or CGI::XML, which shows that there are already enough modules out there to be a replacement or inplacement for the one or the other.

I just, and this is the main reason why I write this, don't get the idea of having a module named CGI::Simple, even if it is not implementing a simpler version of the CGI but just all of it and having a module called CGI which contains more than its name should allow.

Ok, now you can tell me why you thought you could kill me upon having read the first sentence, if that ever was the case :-)


Have a nice day
All decision is left to your taste
Update15.02.2002 12.15 CET
I just had a closer look again at CGI.pm's POD and I think it was 'use CGI qw/:cgi /;' which was (still is?) supposed to fullfill that. So there would by now not even be a need for "-noTags" or the like.
Which does not change my opinion to better move the "baggage and overload" out of the core CGI.pm to other modules in the CGI:: namespace or link them to other modules.

Replies are listed 'Best First'.
Re: Re: RFC CGI.pm refactoring
by mstone (Deacon) on Feb 14, 2002 at 23:34 UTC

    Excellent point: ++.

    CGI.pm is definitely been better than what most new programmers could write on the first try. But by the same token, it would be easier for most people to write their own CGI handler, MIME parser, browser isolation layer, and formatting system than to figure out CGI.pm.

    My own objection to CGI.pm is the interface itself. Interfaces are protocols, and ideally, a library interface should be easier to learn and use than the thing it abstracts. I'd personally argue that CGI.pm's interface is both harder to learn and less flexible than the CGI per se.

    It didn't start that way, but bloat is part of the natural software lifecycle. When something gets so big and unwieldy that people would rather reimplement it than learn the existing version, it's time to clean house. The new versions aren't waste, they're competition, and competition is a Good Thing.

[reply]
      CGI.pm is definitely been better than what most new programmers could write on the first try.

      Now, that's an understatement.

      But by the same token, it would be easier for most people to write their own CGI handler,

      Crap.

      MIME parser,

      Even more crap,

      browser isolation layer,

      still more crap,

      and formatting system

      We're reaching the limit of the sewage system here, folks.

      than to figure out CGI.pm.

      This (one of the worst posts I have seen on Perlmonks (--) rehashes all the arguments put out by stubborn newbies who for some reason nobody can fathom insist on reinventing the wheel every time instead of using good code written by someone else. Witness all those people who refuse to use File::Find and File::Copy. Why, why, why, why?

      Sorry about the rant and the strong language but this is a pet peeve of mine. I feel I made no progress in learning Perl until I started to use its features and modules rather than try to use it as some sort of complex version of C.

      Regards,
      Helgi Briem

[reply]

        First off:

        > Sorry about the rant and the strong language but this is a pet peeve of mine.

        Don't worry about it. People have strong feelings about this issue, and people with strong feelings express themselves forcefully. It takes more than an emphatic response to piss me off. I do like people who can swing back to a more measured tone once they've blown off some steam, though, and will advance you the respect of assuming you're one of them.

        While I think you missed the point I was trying to make, it's clear that the fault was mine, not yours. I expressed myself badly, and your reaction does follow sensibly from what I actually wrote.

        The offending phrase is 'figure out CGI.pm'. Since I was talking about interfaces, it only makes sense to assume that I meant learning CGI.pm's interface. That's not the case, though. What I meant falls closer to 'reverse engineer CGI.pm' -- or even 'read CGI.pm'.

        See, my pet peeve is the idea that programming is a write-only occupation. I think Knuth was absolutely right when he decided that programming is a form of literature. We should be able to sit down with a glass of wine and a batch of source files, and enjoy them just as much as we'd enjoy a good book.

        Good code is fun to read. It expresses the thoughts and personality of the programmer. It can be full of wit, style, and suspense, and can change the way we see the world. There are parts of the Perl source, for instance, that are absolutely delightful. Bad code, OTOH, is torture. And I'm sorry to say that I've had to wade through a lot more bad code than good code, because most programmers never once stop to think that another human might read the stuff. They treat code like it's a love letter to the compiler, and as long as the compiler understands them, they think their code is as good as it needs to be.

        I've read CGI.pm -- several times -- and it's an awful read. It's a palimpset of quick fixes and grandiose schemes that may or may not have been executed with adequate skill. My visceral reaction to it is one of pure rage, and it annoys me to see people enshrine such a monster in the name of an otherwise good concept like code reuse.

        I have more to say, but will post it in a thread of its own, rather than drift too far off-topic from this one. I'll merely note that the number of people who say "use CGI.pm" vastly outweighs the number who say, "read CGI.pm".

[reply]

In Section Meditations