> No module works at all in an absolute sense.
Too true, Moron! Why, Perl itself, and the platforms it
runs on can hardly be said to work, as the requirements
they currently meet will surely change. At least
I assume so; I don't get around enough to really
have a valid opinion.
/blech | [reply] |
The question for your using any given module should be: "does it fit my requirements right now?". If the answer is "yes", then you use it. If it's "almost", then you can either patch the module to your own specifications or roll your own. If it's "no", then you make your own and upload it to CPAN for others to use (if that's appropriate). To say that no module will ever fit your requirements is lunacy.
thor
The only easy day was yesterday
| [reply] |
There is another point that I haven't mentioned: Even though a module may be 99% fit for a purpose, it can still mean 300% extra code to overcome that compared with hand-rolling. This happens so often with File::Find where a complex requirement still only means one extra line per feature in a hand-rolled subroutine, but needs three or four lines of interface plus ten basic lines of code to use the CPAN (in fact core) module, that therefore I find myself not using that module any more.
| [reply] |
So what you're saying is that it's easier to come up with a from-scratch solution than to take one that's 90% there and make modifications? Ummm...
thor
The only easy day was yesterday
| [reply] |
If it's lunacy then why say it. This post seems to be a classic straw man. The rest of your points have already been made by me and others.
| [reply] |
