A Tiny Affordance
What's wrong with this picture?
use parent qw/DBIx::Class::Core/;
Whenever I see that, I've started slowly but surely converting that to this:
use parent 'DBIx::Class::Core';
The problem with using the qw/STRING/ syntax is that it practically encourages multiple inheritance. Is says "gimme a list, really", except that you don't want a list, really. Even a subtle encouragement towards multiple inheritance is a Bad Thing.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
I concur with my learned friend.
But you know there's a PPI API for that...
Read through PPI::Transform, craft a small transform class, and then you can use the transform API to apply it to anything you want.
See
perldoc -f use(http://perldoc.perl.org/functions/use.html). The thing that follows the module (pragmatic) name is a list. When you place a single item (scalar) there, it is automatically converted to a list.I don't know if multiple inheritance is a good thing but all the modern object-oriented languages have it, so I'll reserve judgment.
Shawn? What do you mean "all the modern object-oriented languages have it"?
Single inheritance OO languages:
Which of those isn't a modern OO language?
I think multiple inheritance is a bad thing, but it's good that it's available to us. Once we can more easily alter method dispatch, it will almost be an appendix, though.
Having "enough rope" is almost always a good thing. Keeping most of it under lock and key in the shed is also a good thing.
I've been doing the same thing as Ovid, for the same reason, for a while now, and I'm glad to hear that I am not singularly weird in doing so.
I use the single-quote style because it's shorter and clearer. Why spend the extra two characters making a single-element list when you can make a single-element list without an additional syntactic construct?
I hadn't considered that the quoting construct was an affordance toward multiple inheritance, but I had realized it was an affordance toward passing more options to
import().So, why is multiple inheritance a bad thing? It's a matter of taste IMHO
@Burak: it's more than a matter of taste. Proper inheritance implementation has been a source of bugs and arguments for over 40 years (since the introduction of inheritance in Simula 67). Given that it's confused so many people for so long, it's clearly a code smell.
I could go on and on about the problems with multiple inheritance, but even a quick search on Google shows some of the issues. Ultimately, multiple inheritance tends to be about trying to reuse behaviours rather than responsibilities and it doesn't scale well. I should write more about this and related topics.
If I write about this, the theme will be "are you as stupid as Ovid?" I will never be a Linus Torvalds. In fact, many of the shining stars in the Perl community are far smarter than I am. That's why I strive to find techniques that are easy to understand, implement and maintain. I'm just not smart enough to crack open huge systems and grok them in a couple of days, so I find that I have to try hard to make programming easy.
Well... The main problem seems to be "the diamond" AFAICT, but I'm not sure if this applies to Perl itself since the classes and inheritance is always ordered and you don't need to guess which method is invoked unless some weird things are done inside the methods. But I must admit I wasn't bitten by this problem I sure don't know if it's really bad :)
@Burak: yes, it absolutely applies to Perl. Diamond inheritance is just as much a problem as with other MI languages (arguably more so as Perl can't select methods based on the signature), but multiple inheritance isn't just about selecting the wrong method. It's also about using it to pull in behaviour and particularly with larger systems, it's easy to pull in undesirable behaviour. Classes should define responsibility and roles should define cross-cutting behaviors -- not using multiple inheritance to share behaviors.
Java tried to do this with interfaces (but failed because implementation is not provided), Ruby tried to do this with mixins (and failed because mixins are merely a clever form of inheritance, along with its limitations), others have tried to do this with with aspect-oriented programming (which fails because pointcuts can silently fail to match).
Everyone is trying to solve the inheritance problem. Don't trivialise it in Perl. It really is serious. If you have the stomach for it, try reading this traits paper. It does a decent job of giving and overview of the problem, but you'd probably need to read the citations to fully understand it.