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.

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:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

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.

I guess we have different definitions of private then. If somebody needs to know about and understand a method to be able to subclass a something successfully then I would want that documented and available to all - rather than buried in the source.

When I write OO code I do not want to have to read all the source of my superclasses. To me that's one of the advantages of abstraction and encapsulation :-)

Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations.

For me the advantages outweigh the disadvantages (and things like Class::InsideOut deal with most of the latter.)

Another issue is that your tests may not be valid for subclasses.

True - but I think that would mean:

• I'm testing something that's not intended to be subclassed - so I don't care.
• I've made a mistake in the design - since subclasses should be a specialisation of their super class. That's what an isa relationship says to me.

I'm not saying that it's always a good idea to install test classes - I just don't think it's always a bad idea either :-)