Jesse,
There's nothing stopping you from using delegation in this case either.
All you have to do is make the object you delegate to consume both your
API role and MooseX::Storage, and then have the rest of your code just
use the API role. Using excludes is basically always the wrong answer.
For instance:
package MyStorage;
use Moose::Role;
requires 'load', 'store';
package MyPersistentThing;
use Moose;
# MooseX::Storage implements 'load' and 'store'
with 'MyStorage', 'MooseX::Storage';
# ...
package MyClass;
use Moose;
has persistent_thing => (
is => 'ro',
does => 'MyStorage',
handles => 'MyStorage', # this delegates only 'load' and 'store'
);
Hmmmm ... so, invent a whole new class whose sole purpose is to make it
so I don't have to use `excludes`? Respectfully, I'm not sure I can see
that as better. It appears to be multiplying entities beyond necessity,
first of all, and it adds a layer in my modeling that's bound to be
confusing to whoever comes after. One of the things I absolutely love
about roles is that they effectively increase the expressiveness of your
modeling by adding adjectives to your nouns and verbs. This solution
turns turns my adjective into a noun, making my sentence a lot more awkward.
I think that _if_ I were going to do something like this, I'd rather
move the useless noun down a layer (or up a layer, depending on your
POV). I could create a class which consumes MooseX::Storage, and then
have an attribute of that class in MyStorage. At least that way the
ugliness would be hidden from the client. The modeling would still be
rough, but you could try to think of it like implementing "Feathery" in
terms of "Bird-Like" and needing to have a "Bird" in there somewhere.
Sort of.
I'm still not convinced that's a better solution than using `excludes`
though.
So I guess I'm saying that I'm perfectly willing to accept your
assertion that "Using excludes is basically always the wrong answer" ...
but only if you can give me a better one. ;->
-- Buddy
