On Jul 15, 2010, at 5:51 PM, Kate Yoak <k...@yoak.com> wrote: > > 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. >
There are several options you can use to get around this. One is to use a DuckType instead of a Role here. Thanks to Sartak you can pass a duck type to handles and it will just work. This will catch typos etc. Further down the evil chain, but less evil IMO is handles => qr/.*/ which will delegate *every* method through. Using a regex like qr/^[^_]\w+/ should exclude private methods (starting with _) . It is evil but less evil in my opinion thn AUTOLOAD. Look closer at delegation again. The answers there may surprise you. -Chris > - Kate >
