Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

Let is_red(x) be a property provable about objects x of type FireEngine. Then is_red(y) should be true for objects y of type YellowFireEngine where YellowFireEngine is a subtype of FireEngine.

It just seems like the above is something you might want to do...override some attribute in a sub-type, yet Liskov won't let me do it. I guess I'm glad perl doesn't enforce the Liskov Substitution Principle...or am I completely misunderstanding?

Subclasses should respond to the same methods as their superclasses. I thought you wanted to wipe out a method so a subclass didn't respond to it at all. If not -- if you just want to have a method do nothing -- then it's not a violation, and I misunderstood.

In this instance, I don't really care whether the methods do nothing or are wiped out. In the interest of nearly full disclosure, here's what I'm doing...

I've wrote a class for a particular thing, and there might be 30 or so attributes in this thing, and I want to validate some of these attributes according to certain rules and policies (some of the policies are more like warnings, as in "there might be a problem"), so I wrote validate_<attribute> methods for each thing I wanted to validate. I wrote this for my department, which has certain policies, and now I find I need to write the same sort of thing for another department.

Some of the validation rules are global, but some are just for my department. So I'd like to skip some of the attribute validations in the sub class for now, but leaving placeholders for future validation code seems like a good thing (whether subs with empty bodies or subs that do nothing). The "right" thing to do might be to write a base class with just the global rules, and subclass both modules from there, or maybe write just a Validation subclass, but in the interest of doing less work, I'm just using the first module as a super class for the second.

The actual things may have already been put into production before policies have been created, so the ability to create and manipulate objects with possibly "invalid" attributes is desirable, especially since validating things is not the only thing this module does.

Update: With only one subclass and still total control, there's still time for refactoring, so it might not be a bad idea to separate the global rules from the departmental ones in the near future, and work something out that way.