Ovid,

On Apr 28, 2009, at 8:59 AM, Ovid wrote:
----- Original Message ----
From: Stevan Little <stevan.lit...@iinteractive.com>

I am also very much not a fan of adding features to solve problems that are easily solved in other ways. Moose already has a fairly large feature set and I am pretty adverse to adding more unless they are first vetted through a MooseX:: module (see the section on NEW FEATURES in Moose::Manual::Contributing).

I don't particularly care for the idea of creating an interface role for every role which might also serve as an interface because that violates chromatic's insistence that things be easy lest we discourage people from using roles to their full power.

I fail to see how chromatic's opinion matters for $work code. I agree with him, but you are working on a complex code base not a "how to use roles the chromatic way" document :) Roles should be easy, but they should also be capable of being building blocks for complex solutions. Some problems are not simple and so will not have simple solutions.

I also am of the opinion that roles are not a silver bullet. I have been using them in real-life code and/or pondering them heavily for something like 5+ years now and I strongly feel that while they are very powerful, they should be used judiciously. Overuse of roles is only slightly less worse then overuse of MI, but judicious use of roles is far superior to almost any use of MI.

Of course this is my opinion only, so take it with a grain of salt please.

That being said, I'll look at the MooseX route.  Thanks.

Check with Sartak, he was working on trying to make this kind of stuff easier. He may have some good tips.

By the way, was this really a bug?

  #!/usr/bin/env perl

  package My::Role;
  use Moose::Role;
  sub foo { __PACKAGE__ }

  package Bar;
  use Moose;
  with 'My::Role' => { excludes => 'foo' };

  print Bar->foo;
# Can't locate object method "foo" via package "Bar" at role.pl line 13.

That shouldn't be a runtime issue, but a composition time failure. Should I file a bug report?

IIRC, when excluding a method and composing into a class it just ... excludes. When excluding a method and composing into another role, the excluded method becomes a required method. I might be wrong, but I would have to do some source diving to see.

- Stevan


Cheers,
Ovid
--
Buy the book         - http://www.oreilly.com/catalog/perlhks/
Tech blog            - http://use.perl.org/~Ovid/journal/
Twitter              - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

- Stevan


On Apr 28, 2009, at 3:53 AM, Ovid wrote:


There are times that you want to use a role, but only as an interface.
If 9 out of 10 classes use the implementation, it's annoying to have
that 10th class have to do this:

with 'My::Role' => { excludes => \...@a_long_list_of_methods };

What about something like this?

with 'My::Role' => { includes => [] };


That
would be the mutually exclusive opposite of 'excludes'.  No methods
would be composed into your class, but they would all be added to the
'requires' list.  This (I think) would largely overcome chromatic's
objection (http://use.perl.org/comments.pl?sid=42835&cid=68295)
that if someone wants to use a role as an interface, being forced to
manually exclude every method is annoying and would discourage role
use.  So a role could be trivially used as an interface, if desired,
even if implementation is provided.

Plus, if you still needed two of the 8 methods a role provided:

with 'My::Role' => { includes => [qw{ foo bar }] };

Seems to me that this is the best of both worlds. This would also make it
trivial to add the "warn on conflict" back in because the entire objection seemed to be that the warning coupled with it being annoying to exclude all methods would discourage role use (an argument which penalizes the programmer who values safety and correctness, but then, Dominus doesn't like how we constantly encourage "use strict", either). While I do realize I've lost this argument, at least adding "includes" would make roles a tad more flexible and make some of my work easier if I get around to writing "MooseX::Role::Strict".

This
also shows what I *think* is a limitation in 'excludes'. All methods
listed in a role should be explicitly added to the 'requires' list.
The following is a runtime failure:

  #!/usr/bin/env perl

  package My::Role;
  use Moose::Role;

  sub foo { __PACKAGE__ }
  package Bar;
  use Moose;
  with 'My::Role' => { excludes => 'foo' };
  print Bar->foo;
# Can't locate object method "foo" via package "Bar" at role.pl line 13.

Thoughts?

Cheers,
Ovid
--
Buy the book         - http://www.oreilly.com/catalog/perlhks/
Tech blog            - http://use.perl.org/~Ovid/journal/
Twitter              - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6


Reply via email to