Wonderful, we invent a perfectly good way to group code,
make it easy to update, and even work together to fix it
and get the word out about bad versions so that everyone
shares in the benefits...
Then you come along and ask them to throw that all away
over a few paltry microseconds. And chance screwing up the
code. And miss out on any redefinition done by other modules through
inheritance. And the next time they need to modify the
script and just need one more function from CGI they go
back to file and try and find it. And they disconnect the
functions from the object they work with, potentially breaking
all kinds of nice optimizations and friendly features that
the full CGI offers. And they wind up pulling over half
the module for all the support code anyway and blow off
the conditional instantiation so that their code actually
winds up bigger in memory.
Here is a hint for the inexperienced monk, your time
spent coding is likely to be millions of times more
valuable than the time you will save second-guessing and
re-inventing the best modules that Perl has to offer. CGI
is so good and so valuable to the Perl community that they
stuck it in the core so that everyone has it!.
--
$you = new YOU;
honk() if $you->love(perl) | [reply] |
I totally agree with you. Let me ask the person who suggested that we not use CGI.pm? Do you have as much experience in Perl as Larrry Wall - obviouslly not. As much as Lincoln Stien? I sincerley doubt it. Then why would you doubt their judgment in including (as extremely said) CGI.pm with the core Perl package? So instead, you would rather waste time copying routines from the CGI module (some of which I have a feeling you know nothing about) into a new module of yours - untested - and use that?
Listen, the people who write these modules know what they are doing, and the people who decide to include them understand that the benefit of that module will be great on the Perl community, so just trust them. Well, thats my two cents, atleast.
R.Joseph
| [reply] |
Still worried about the time it takes to load CGI? Using a persistent-state-CGI webserver or webserver module is your answer. Because you do have a valid concern, these modules are depended on heavily, are well-tested, and work great! Try FastCGI or mod_perl for more details.
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
Disclaimer: I don't regularly use CGI.pm, notably because I do very little web-based work.
Correct me if I'm wrong, but doesn't CGI.pm do dynamic loading (i.e., if I don't call one of its methods, it doesn't load that bit)? I'd be curious to see your benchmarks that indicate that your separate module was twice as fast as using CGI.pm...
| [reply] |