All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Well, Now I Know (Roles)
In Pondering Role Organization, I was trying to figure out if I want an abstract base class or not.
He's code with the abstract base class:
package Order;
use Moose;
extends 'My::ResultSource';
with qw(
DoesAuditing
DoesCustomerSearch
);
...
Here's this code using only roles:
package Order;
use Moose;
with qw(
DoesResultSource
DoesAuditing
DoesCustomerSearch
);
...
We've elected to go with an abstract base class here at the BBC. I now realize this is a mistake. In fact, I think it's a bad mistake, the sort which an amateur chess player might make.
So let's saying that you're playing chess and you open up with a classic "Ruy Lopez". It's hundreds of years old, it's a strong opening, and it's very powerful. After about 6 or so moves, you decide you don't like it and you switch to a hyper-modern opening. In the Ruy Lopez, you attempt to control the center by occupying it. In hypermodern strategies, you control the center from the periphery. Each has strengths and weaknesses and it's not impossible to switch from one to another within in a game, but if you do this all the time, you're probably losing more often then you win. This is because of an age-old rule: given two players of equal skill, the player with a bad plan will beat the player with no plan. Arbitrarily switching strategies in the middle of a game is equivalent to having no plan. Mixing inheritance and roles is like trying to figure out which strategy you want to adopt.
The only benefit I could see to using an abstract base class is to be able to say $object->isa('My::ResultSource'), but what benefit does this have over $object->DOES('My::ResultSource')? Absolutely none that I can see. In fact, by using an abstract base class, we lose the ability to get composition time detection of method conflicts. Silently overriding methods is a mistake.
<digression>
Not everyone agrees that silently overriding methods is a mistake. Here's my reasoning, based upon many hours of painful debugging.
Many languages such as Java, C#, Ruby and others don't allow multiple inheritance (MI). This is due to how easy it is to silently "skip" methods. Every language which forbids MI provides some way of working around this, though, because some problems cannot be solved merely through class composition. A later version of my Refactoring With Roles talk (not online, I'm afraid), gives one such example.
Many languages, even those which forbid MI, also force you to be explicit about whether or not you're overriding a method. C++ fails because you must declare a method as "virtual" in the base class, so the concrete class has no visual indication of this (outside of an IDE helping out), so the programmer has to root around in the base class. Even compiling the code won't necessarily help because you may have introduced a bug that even your tests won't necessarily have found.
Eiffel actually does a great job of managing much of this, forcing the programmer to be explicit about everything, but they still lock you into a class hierarchy and the attendant composition problems which may arise. As biologists have discovered in trying to classify animals into species, genus, family, etc., a simple hierarchy doesn't work and OO graphs don't necessarily map well to the "genes" of an object. Many, many languages struggle with this problem and get it wrong, or at least have varying degrees of "right". It's a hard problem and one that needs to be solved at the language level, not the developer level.
As a result, there's a certain minimum level of complexity which any large-scale system and when the computer can find potential problems -- particularly when it's close to compile time -- this is far better than requiring the programmer to always look for those potential problems. Remember, we have computers for a reason. They do our grunt work for us. And here's the key to all of this: because the programmer, under a tight deadline, with complex code, often poorly documented, overrides a method they missed, despite diligently reading as much as they can, silently overriding said method hurts him, particularly when the fix is both trivial and well-understood. With roles, the fix is trivial and well-understood.
</digression>
To me, the silent overriding of methods is the final nail in the inheritance coffin for Perl. However, I realized after a while that there are other considerations, some unique to Perl and some not.
In Perl, we don't distinguish between class and package names. If a package name is brought in via use or require, we are tightly coupling this package name to a path on disk. As a result, we are generally coupling OO behaviors to disk layout. This is a marriage made in Wonderland. It's not necessarily wrong, but it's decidedly odd. Frankly, I want my disk layout (different directories) to reflect the different facets of the system I'm working on, not necessarily the class layout.
By dispensing entirely with inheritance and relying solely on roles and forbidding silently overriding methods, we can guarantee a certain minimum level of sanity at composition time. This, interestingly, is one of the strongest benefits of static typing. By properly modelling behaviors and forbidding ambiguity, we can mitigate one of the most reasonable objections to dynamic languages.
We also no longer have hierarchies. Objects can be placed anywhere in your directory tree to properly reflect business requirements rather than technical ones. Yes, we'll still have coupling across directories/packages/classes, but you always have that in systems: the bits have to be able to talk to one another. That being said, class composition errors go away. MRO problems are gone. Open up a class and you see all of its behaviors listed at the top[1] rather than rooting around through base classes, trying to remember their order and hoping you know what overrides what. Complexity management for large-scale systems becomes easier.
I realize that much of this seems like "pie in the sky" talk, but so far, it's working out well for us. This is real code which is solving a real problem. No, this is not a Holy Grail or Silver Bullet, but it seems like an huge step in the right direction. I'm quite pleased.
--
1. This may imply that roles do not consume other roles. This is the strategy I am following. I only want a role to consume another role if that other role is merely an identifier and perhaps an interface:
Package DoesSearch::Tags;
use Moose::Role;
with 'DoesSearch'; # no behavior. Just a name.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
On Warnings (Score:1)
This is not a case where the computer can identify problems with certainty. The compiler cannot judge your intent. Did you make a typo in the name of a class-local method such that it collides with the name of a composed method? Did you forget to read the documentation? Did you do it deliberately? Did someone up
Re: (Score:1)
Imagine if Perl warned you every time you used a package-scoped variable only once. Sometimes that's a mistake -- perhaps often, it's a mistake. It's not always a mistake.
Imagine if Perl warned you every time you redefined a function (for example to memoize or inline it). Sometimes that's a mistake -- perhaps often, it's a mistake. It's not always a mista
Re: (Score:1)
I call: The Value of a Warning [modernperlbooks.com].
If you believe that the only purpose of roles is compile-time, warning-safe mixins, you're missing at least half of their power.
The purpose of roles -- the real, get your hands dirty, oh wow this is an epiphany moment of roles -- is to produce a type system that tracks the capability of entities without dictating their particular implementation of those capabilities.
In a true role
Re: (Score:1)
I responded at my blog [blogspot.com] with a description of both sides of the argument. The gist of it is: the warning is gone, and we will support the warning Ovid needs (and much more) as Perl::Critic policies.
Re: (Score:2)
Please note that I'm not trying to change your opinion here because it's obvious that we strongly disagree here. I provide this for anyone else who may be reading this.
This is not a case where the computer can identify problems with certainty. The compiler cannot judge your intent.
And that's why the warning is so desperately needed. If I inherit from A and B and both provide a "foo" method, I usually get the one that I've inherited from first. One could argue that I forgot to read the documentation or that I did it deliberately, but just like the composition problem I list above, there's no way that the compiler can
Re: (Score:1)
Yet when I override multiple methods (or all of the methods) from a role for the purpose of complete allomorphism or delegation, your approach means that I have to exclude every one of them explicitly, which is mere busy
Re: (Score:2)
For the case of overriding everything or almost everything and the role is not simply an interface, then yes, the work to exclude all of the role's methods would be annoying. That's the only interesting argument I've heard from this entire discussion and had the discussion started out with this, then things might have gone easier.
The problem is that your solution is still throwing away information, my solution can be cumbersome at times. So the reality is that this is a syntax issue. If a good, clean syn
Re: (Score:1)
mst has some very nice examples using
MooseX::Declare, where you provide a block after applying a role. Any method you define in that block very obviously takes precedence over methods composed from the role.Re: (Score:1)
Re: (Score:2)
I can easily imagine this. If you simply want to say "I provide this behavior" but your implementation differs significantly, you might override all of the roles (this is different from an interface because the role can also provide an implementation). The issue is that this is the use case that chromatic wants to support and I'm against silently discarding behavior.
Re: (Score:1)
Re: (Score:2)
Let's say that you can serialize an object as HTML. You might use the role Role::Serializable::HTML with a &serialize method. Then someone can ask:
By providing a name for the behavior, you are guaranteeing to someone that you provide a &serialize method and that it will serialize the object as HTML.
However, and this is chromatic's concern, it's quite reasonable that the object might want to use that r
Re: (Score:1)
I've written a lot of mock objects, and I've had to work around a lot of code which performs its own type checking. That can interfere with the work of mock objects. I plan to write an article with more concrete examples soon, but for now I hope it's not too abstract to say that the question "Is this entity a member of an inheritance hierarchy at this point or lower?" is much less interesting and much more difficult than the question "Does this entity perform the behavior I expect?"
Re: (Score:1)
Tell me with a straight face that it's not crazy to use a module and then be forced to list all of the methods that you want to import because it didn't define @EXPORT. Particularly when the only reason why someone would want to use that module is to get access t
Re: (Score:1)
The important difference is that roles have always had the explicit design goal of not enforcing any particular implementation decision to take advantage of them.
Re: (Score:1)
The fact that someone has a legitimate design goal that creates action at a distance doesn't necessarily make the decision to create action at a distance a good idea.
In a similar spirit I would not be opposed to an optional warning if my subclass overrode a parent class's method and didn't, say, provide an attribute that says, "Yes, this is an intentional override, don't warn." You might find having to type :override annoying, but I would find it invaluable. (I also know that I have a snowball's chance in
Re: (Score:1)
I believe it's easier to argue that inheriting or composing in methods is more action at a distance than declaring them locally. Perhaps prototype OO systems are clearest by this metric.
sin / cos (Score:1)
I noticed you are using a role called 'ResultSource'
Are you using DBIx::Class?
If so, how are you integrating it with Moose? Are you extending the DBIx::Class'es or are you wrapping the storage object (the row)?
That is, do you have two classes for each business entity: one for the model and one for the storage (DBIx::Class)?