Roles in p5-MOP
Support for roles has now been added to the p5-mop-redux project. I ported the example that I used a few times in talks and in previous p5-mop attempts. I like this example because it shows a number of features and styles of roles, such as; required methods, roles composing into roles, interface roles and finally multiple roles composing into a class.
Over the years I have written a number of implementations of roles, it started with Class::Trait back in 2004, followed by a couple of attempts in the Pugs project, then came Moose::Role and most recently in the old p5-mop project - and I never really liked how any of them turned out. The implementations always felt overly complex and never seemed to gel in my head completely. Since I am really striving to keep things simple with this version of the MOP I decided to avoid the crazy bootstrapping gymnastics and start with the simplest hack possible (then clean it up in the bootstrap).
And I am happy to say, it worked out! ... and as a bonus I accidentally created a new feature; abstract classes. Abstract classes are simply a class with a required method, they will compile, but will fail if you try to instantiate them. This also created a change in how roles and classes work, composing a role with a required method into a class, and not fulfilling that requirement will no longer break at compile time, but instead will create an abstract class. I am unsure if this is actually a good thing or not, but I want to experiment more with abstract classes before I pass judgement.
Next goal is to refactor some of the guts of attributes so that it is both more correct (ultimately meaning more extensible) and faster (basically making things lazier).
I blog about Perl.
Abstract Classes have uses, leave them available, better yet make them a first class citizen and allow required but unfullfilled methods directly in classes. Abstract Classes are in the spirit of TIMTOWDI.
I'm not saying Abstract Classes are usually the right way to do it, but with Moose they are sometimes the only way to get code reuse (without building another extension). The only reason not to allow them is an attempt at idealism, assuming that you will not create a scenario where you can solve a problem with inheritance that you can't solve with role's.
Caleb – Don't worry they are staying as a feature, its just the exact details of how they work, etc. that is up for discussion right now.
I also am unsure if it's a good thing, but it doesn't seem like a bad thing per se. If it gets us there and simplifies the code, it seems like a nice compromise, Yes, I want the compile-time safety, but I could definitely live with this.
Ovid – Actually my plan is to require you to declare your class as abstract, otherwise it will behave much like Moose does now if you do not fulfill all the method requirements. I feel that this gives it the best of both worlds.
As a former C++ programmer, I've always felt abstract base classes would be a useful addition to Moose. I've used MooseX::ABC for this purpose, but it always felt a bit clunky. So I'm glad to see this accident happen. :-)