Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
We already know that multiple inheritance is bad. So I'm not surprised about the reported multiple inheritance Exporter bug. What I am surprised about is that this behavior still surprises people. Clearly more education is needed. So here's some education for you:
Multiple inheritance is wicked and wrong and you shouldn't use it!
It used to be the case that you might be able to make a weak argument for this abysmal practice. With roles, I'm hard-pressed to think of any excuses. Stop using multiple inheritance.
Given how many times I warn against absolute terms like "never" and "always," I'm on thin ice here.
Bit me the other day (Score:1)
Design Concept Good! Implementation Bad! (Score:1)
Multiple Inheritance is a fundamental OO concept.
The only programming language I know that *safely* implements it is Eiffel.
Most people who get in trouble with MI don't realize the fundamental danger of method name conflicts, and how they must be resolved. That is the issue with the bug you reference (not in Exporter after all, but with Class::Accessor::Fast).
OOSC2 (Meyer, 1997) highlights two "interesting issues" a
Re: (Score:2)
Roles is not an alternative to the design concept of Multiple Inheritance
What's the design concept of Multiple Inheritance?
The problem with OO as it's usually conceived is that classes are used both for their responsibilities -- which tends to make the classes larger -- and for behavioral reuse (frequently via inheritance). When you want to share behavior in a procedural module, we know that it's usually a bad idea to have modules automatically pollute your code with a bunch of functions you didn't ask to import. You should ask for them explicitly (via @IMPORT_OK if using Expo
not to mention... (Score:1)
...why would you use Exporter when Sub::Exporter is right there? I mean, it's practically a parameterized role itself...
rjbs