|Perl: the Markov chain saw|
I think some perspective is required here. I agree that "can you do it? then do it" protocols are adding superfluous logic. However you do want to take different actions depending on what kind of thing you have. It doesn't make sense to have every object accept every possible message ever but ignore all but a small set of them (because it can't handle the rest) - does it? mvc was arguing to decrease coupling, but he also conceded that the ultimately independent object is one that has no methods and is ultimately useless. What you really want to do if you are concerned about purity and want to loosen coupling is having the conditional be implicit in the $token's class. See evolving an OO design for this principle. Loose coupling is achieved by removing the condition from the calling code altogether.
In the case in question, the correct approach would be to have a different class for every type of token, and to define a ->clean_up method for each of them. The one for a start tag would delete font attributes, in others it would be a no-op. Then, you just write:
Is that worth the effort? It depends on the scale of the project.
I would like to argue in favour of enforcing the difference.
That would necessitate "can you do it? then do it" for small scripts (which I believe are more readable for it). In large projects, it would be very helpful to have the strictness enforced as an extra debugging tool. If I mix up the types of objects at some point in the code, letting all of them accept any kind of message is not going to help me track down the error.
If inconvenience for small scripts is a concern (though that isn't what you were asking about), I would possibly add a strict => 0 option to the constructor.
Makeshifts last the longest.
In reply to Re: OO style question: how much information to hide?