Re: Why breaking can() is acceptable

[Ovid]

For the most part, I agree with your assessment of the problem. However, I don't know that I agree with your solution because your solution attempts to deal with fundamental problems in Perl's OO model. Here are my thoughts.

First, programmers tend not to worry about these issues (and are less likely to encounter them) if they're building small systems. If they're building large systems, those programmers had durn well better know about those issues.

Second, I don't believe it is appropriate for programmers to attempt building large systems without a test suite. A good test suite will nail problems like this. If you find a bug, you add a test. This might seem to be irrelevant to your concerns, but I've found that with tests, while I write better code, I also worry less about constructs that I previously would have avoided due to apparent fragility.

Third, these issues are, of course, exacerbated when multiple inheritance is used, but programmers should usually be be delegating instead of inheriting. If UNIVERSAL::AUTOLOAD is searching a huge inheritance heirarchy, I submit that the system probably has some design issues. Scalability in Perl should usually not be achieved via complicated inheritance heirarchies. That's begging for trouble. Abigail's inside out objects can help, as can lexically scoped subs for private methods (my $sub = sub foo{};) and traits, but the reality is, Perl's OO has some quirks that people should be paying attention to. can seems to be pretty far down the list.