They don't have to look to my distribution to figure out how to code the subclass
Maybe, if the subclasser both is disciplined and doesn't want to do very much (like add new attributes). However, a lot of subclassing involves overriding private methods, adding new attributes, and other potentially invasive procedures. As such, the subclasser will need to read the code in order to understand implementation details.
Me, I always read the distribution because the distribution may involve OS-specific installation tasks. PDF-Template and Excel-Template both do and I learned that trick by reading other Makefile.PL's. *shrugs*
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Maybe, if the subclasser both is disciplined and doesn't want to do very much (like add new attributes).
One of the reasons I like inside-out objects :-)
However, a lot of subclassing involves overriding private methods, adding new attributes, and other potentially invasive procedures. As such, the subclasser will need to read the code in order to understand implementation details.
If somebody has to read my code before they can subclass something then I've not done my job right. If they have to override private methods then I've really not done my job right.
(Not that I'm against folk fiddling for fun/good reason - just that it's almost certainly a sign of a design gone wrong)
Me, I always read the distribution because the distribution may involve OS-specific installation tasks. PDF-Template and Excel-Template both do and I learned that trick by reading other Makefile.PL's. *shrugs*
I've got nothing against reading the distribution. Do it myself all the time. I'm just questioning whether having test suites be a "distribution only" thing is necessarily always the sensible option.
Rather than think of test classes as *.t files - only useful at installation time, it sometimes makes sense to look at them as application-specific Test::* modules - of general use to people who use the module.
| [reply] |
If a user of my module isn't supposed to use the method, then it's private, subject to change without notice. However, my subclasses will probably want to override some subset of these private methods because that's where the meat of the work is happening. Hence, they need to read my code.
Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations.
Another issue is that your tests may not be valid for subclasses.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |