On Jul 15, 2010, at 10:30 AM, Jesse Luehrs wrote:

> On Thu, Jul 15, 2010 at 10:11:04AM -0700, Karen Etheridge wrote:
>> On Wed, Jul 14, 2010 at 09:28:35PM -0500, Jesse Luehrs wrote:
>>> Nope... you can't magically turn a class (even a non-Moose class) into a
>>> role... roles just don't work like that. Sticking with extends is really
>>> your only option for dealing with non-Moose code.


Thanks everybody for creative responses. I find Roles to be a wonderful 
concept. I believe that the vast majority of the time we use inheritance, what 
we really mean is Role. So, in a way, turning a non-moose class into a Role 
serves an even more important cause than moosefying - it creates a cleaner 
paradigm. So while, for now, I am sticking with inheritance, I'll add it to my 
moose wishlist (to look at when I retire, perhaps!) 

>> 
>> I see a few options:
>> 
>> 1. copy your framework code into a Moose role (i.e. "refactor")
>> 2. import the functions from the framework into a Moose role, using
>> Exporter.
>> 3. create a Moose role which has one attribute, an object handle which is
>> an instantiation of your framework, and use delegations (i.e. the 'handles'
>> option) to tie methods from the role into the framework class.
> 
> 2 won't work, because Moose treats exports different from methods (this
> is why you can do "use Scalar::Util 'reftype'" in two different roles
> and not get a method conflict). And I assumed that if 1 was reasonable,
> we wouldn't really even be having this discussion(: But it's true,
> delegation would be another potential option.
> 
> -doy

Right, (1) is not very interesting, particularly because you might as often 
want to make a Role out of a cpan module as your own library.
(2) could work with something like Sub::Name or other suggestions described in 
an older thread on a similar topic:  
http://www.nntp.perl.org/group/perl.moose/2010/05/msg1606.html
(3) handles has let me down :-(
It's ok when you want to handle 2-3 methods, but not when you want true and 
complete delegation (as in Karen's suggestion).  I really dislike the idea of 
typing up every method name the class has implemented within handles and have 
that be a predictable source of long debugging sessions as the code changes.  
When I want to use complete delegation, I have, for the moment, settled on 
AUTOLOAD.  It's a bit ugly, but I like it better when we truly mean transparent 
delegation a la inheritance.

- Kate

Reply via email to