|P is for Practical|
Your class then has an obligation (IMO of course) to provide a working version of can in its interface.
If we are talking from an OO purity point of view, I would agree. Anything that breaks inheritance is evil and must be avoided.
OTOH, a lot of people agree that multiple inheritance is needed in some cases, but there is no good way to implement it. How do you handle dimand inheritance? In what order do you call destructors (something that's been an issue on the Squawks of the Parrot blog of late)? There's no good answer, and an awful lot of bad ones.
Abigail-II gave a great example in this thread of how easy it is to break inheirtance in Perl (one which I hadn't considered before). If you implement your class as a hashref, all your parents and subclasses also must use a hashref. Which might be the most common case, but it isn't the only one.
Observation: this thread is a case study in why Perl's object system is hacked on.
Note: All code is untested, unless otherwise stated
In reply to Re: Re: What is this can() and why is breaking it (un)acceptable?