I've just uploaded Class::CGI 0.10 to the CPAN and it should hit mirrors soon. I've finished implementing better error handling and while enhancements to the module are anticipated, it's essentially feature complete. However, when I put out an RFC about this module, some folks hammered me for "reinventing the wheel". After all, numerous other modules, including the excellent Data::FormValidator, solve the problem that Class::CGI attempts to solve. So why would I reinvent a wheel? After all, I've warned other people not to do that. Doesn't that make me a hypocrite?
I've reinvented this wheel for the same reason I don't have Z-Rated tires on my car. Z-Rated tires are softer and more expensive than regular tires and they don't last as long. Why on earth would someone want to buy them? It's simple: because of how Z-Rated tires are designed, they grip the road better than regular tires and are excellent for cornering at higher speeds. I don't need them on my car, but a high performance car does need them. Reinventing this wheel is necessary because the car being driven needs different behavior.
To stretch the analogy further, you wouldn't want to put a car's tires on a motorcycle. Or imagine trying to put them on a train! You can't. Even though all of the tires solve the same basic problem, they do so in different ways. It's OK to reinvent a wheel if you have a particular itch which needs to be scratched. CGI::Simple, the module upon which Class::CGI is based, is an excellent example. It passes all of CGI.pm's tests for which CGI::Simple is implementing duplicate features, it omits the HTML generating code, it's faster and it doesn't try to provide the features in both an objective and functional interface.
So when you should you not reinvent the wheel? You should probably not do this if you can't demonstrate a clear difference in what you're offering or you don't have a good understanding of the problem you're trying to solve. Sure, it's OK to do this as an exercise to better understand the problem space you're working in, but most folks who reinvent the wheel seem to do so very badly. They turn out buggy code which doesn't offer the features that well-established alternatives provide.
Class::CGI may not fit your particular needs or coding style, but it's clean, easy to use and is markedly different in approach from the alternatives (which are listed in the "See Also" section of the docs). Don't dismis the module merely because I'm offering a Z-Rated alternative to what you're currently using.
Cheers,
Ovid
New address of my CGI Course.
Not to nitpick too much, but I clicked on your CGI::Simple link because I wasn't sure which of the two modes (function vs object) it would deign to not support, as I suspect that the large majority of CGI users are fairly evenly split, and failing to support one mode would prevent half the potential "market" from being interested.
So, I found that CGI::Simple claims to support both. Which is goodness. Not that I have any desire for using the functional interface, finding it much more invasive than the object interface (I like keeping my namespaces as clean as possible, but no cleaner). But it's nice that it's supported for those who baffle me by liking the other way ;-)
I don't think, however, that this negates your point - some reinvention is a good idea when that new invention is still new in some way. Otherwise, we'd all still have stone wheels for tires. Or we'd still have processor speeds measured in KHz, nevermind GHz. Think of it more of a "discovery" of a different way to solve the same problem, with its own pros and cons.
With regards to the module, I think its fine to publish a different approach to a common problem. You have scratched your itch, and if the code is compelling, others will take it up as well.
That is the beauty of the free market of ideas - only the most fit (for some definition of fit) survive and grow. The market can accomodate any amount of sex and mutation of memes and still produce wonderful software over time.
-Mark
I like the profile filtering you did with the "use" section. Other than that, I must still be missing the point. But this isn't an RFC, so I'll be quiet now (he said timidly ;^)
- Out of balance
- Not round
- Flat
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."You reinvent wheels when they are:That's funny, but it's wrong:
- Out of balance
- Not round
- Flat
- If your wheel is out of balance, you realign it
- If it's not round, you tweak the spokes until it is
- If it's flat, you fix the puncture and re-inflate
You reinvent wheels if your current wheel:
- melts on hot tracks
- has no traction in the rain
- takes 30 minutes to change
Remember, Ovid is talking about race cars. The existing wheels were fine as wheels go, but they didn't bring him to the finish quickly enough, or didn't fit on his car.
I agree. I also agree with the person to whom you replied.
The problem with a metaphorical statement of principle like "don't reinvent the wheel" is that it then allows infintely variable refinements to produce analogies to demonstrate related principles. For purposes of demonstrating that one should violate the rule about reinventing wheels when the previous wheel is not sufficiently functional, the previous comment was apt and effective. For purposes of demonstrating realities made more obvious and prevalent with the increasing awareness of open source software development methodologies, your comment is more apt and effective.
The benefit of metaphorical statements of principles like "don't reinvent the wheel" is two-fold: both that it gets the point across quickly, clearly, and profoundly, and that it does everything I just described as a problem above. Sometimes it's a problem, and sometimes it's a benefit, but usually it's both.
|
- apotheon
CopyWrite Chad Perrin |
We learn how common things are done, thus enhancing our knowledge and experience
We may even find a better way of doing it
Just my 2 cents.