The obvious one: don't use a module.
My initial reaction to this snide remark was to dismiss it as yet another exercise in sarcasm. However, looking back at my post, I suppose I didn't make it clear that the purpose of the seminar is to teach the inside-out technique, and, particularly, its pros and cons. I also want to give an overview of the "gazillion" modules that are springing up, so people understand what each one brings or doesn't bring.
As to the gazillion modules, what's the alternative? Every programmer going out and making their own gazillion mistakes writing everything by hand? At least CPAN modules, flawed as they might be, have the potential to benefit from some degree of peer review, experience and bug reports. (c.f. the growing Class-Std bug list)
What I find slightly amazing is that none of the tech reviewers for PBP picked up on any of the potential design issues before Damian went out and declared inside-out objects as the a new best practice.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
As to the gazillion modules, what's the alternative? Every programmer going out and making their own gazillion mistakes writing everything by hand?
That's like saying everyone should take a cab into work, instead of driving yourself and create car accidents.
We've already established that all the modules have their flaws (otherwise, we'd quickly agree what module to use). And frankly, inside-out objects are simple. Hardly more complicated than hash based objects.
Give programmers a bit of credit.
| [reply] |
| [reply] |
| [reply] |
You may say "drawbacks", others might say "features". If a particular implementation does exactly what you need, why not use it?
| [reply] |