Skip Menu |
 

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 97604
Status: open
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: DROLSKY [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Replace Moose::Exporter's meta_lookup allback option by looking at init_meta return value
Download (untitled) / with headers
text/plain 687b
This is mostly a note to remind myself of my thoughts on this ... While I was working on MX::Role::Parameterized I had some issues with its use of meta_lookup. It does some dangerous and fragile things to make sure that Moose::Exporter and other code sees the right meta object while it's in the process of generating a parameterized role from a parameterizable role. It occurred to me that we can ensure we have the right meta object by simply capturing the return value of init_meta() calls and passing that object around to where it's needed. This needs more investigation, but if I'm right we could simplify the internals a fair bit, and make MXRP less bug-prone at the same time.
CC: ;
Subject: Re: [rt.cpan.org #97604] Replace Moose::Exporter's meta_lookup allback option by looking at init_meta return value
Date: Tue, 29 Jul 2014 16:24:38 -0400
To: Dave Rolsky via RT <bug-Moose [...] rt.cpan.org>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 1.6k
On Tue, Jul 29, 2014 at 03:47:05PM -0400, Dave Rolsky via RT wrote: Show quoted text
> It occurred to me that we can ensure we have the right meta object by > simply capturing the return value of init_meta() calls and passing > that object around to where it's needed. > > This needs more investigation, but if I'm right we could simplify the > internals a fair bit, and make MXRP less bug-prone at the same time.
init_meta is actually not required to return anything - the return value has never been used in the past, and there are quite a few existing modules that don't bother to return anything. Additionally, init_meta was intended to eventually just go away, since all of its functionality has been moved into import (unless you actually override it). I don't think any of the modules that do return something return anything other than the $metaclass parameter, though. In any case, I don't think this is correct, because the point of meta_lookup is that MXRP wants to be able to export both 'parameter' and 'method' keywords into the same package, but have them operate on different metaclasses - 'parameter' is used outside of the role block, and applies to the Parameterizable metaclass, and 'method' is used inside the role block, and applies to the Parameterized metaclass. This can't be handled just by special-casing things in the 'method' keyword definition because it also re-exports everything in Moose::Role, so those keywords also need a way to know that they should be acting on the Parameterized metaclass and not the Parameterizable metaclass. I don't know how you would encode this information other than by having something where you could request "which metaclass should I be using now?". -doy
Download (untitled) / with headers
text/plain 2.1k
On Tue Jul 29 16:24:58 2014, doy@tozt.net wrote: Show quoted text
> On Tue, Jul 29, 2014 at 03:47:05PM -0400, Dave Rolsky via RT wrote:
> > It occurred to me that we can ensure we have the right meta object by > > simply capturing the return value of init_meta() calls and passing > > that object around to where it's needed. > > > > This needs more investigation, but if I'm right we could simplify the > > internals a fair bit, and make MXRP less bug-prone at the same time.
> > init_meta is actually not required to return anything - the return value > has never been used in the past, and there are quite a few existing > modules that don't bother to return anything. Additionally, init_meta > was intended to eventually just go away, since all of its functionality > has been moved into import (unless you actually override it). > > I don't think any of the modules that do return something return > anything other than the $metaclass parameter, though. > > In any case, I don't think this is correct, because the point of > meta_lookup is that MXRP wants to be able to export both 'parameter' and > 'method' keywords into the same package, but have them operate on > different metaclasses - 'parameter' is used outside of the role block, > and applies to the Parameterizable metaclass, and 'method' is used > inside the role block, and applies to the Parameterized metaclass. This > can't be handled just by special-casing things in the 'method' keyword > definition because it also re-exports everything in Moose::Role, so > those keywords also need a way to know that they should be acting on the > Parameterized metaclass and not the Parameterizable metaclass. I don't > know how you would encode this information other than by having > something where you could request "which metaclass should I be using > now?".
Doy, you're right. I changed the title of ticket to better reflect my goal. Basically, I don't think we should use meta_lookup _in Moose::Exporter itself_ where we don't need to. We should be able to simply pass the $meta object itself around in some spots. This reduces the possibility of bugs that come from complicated meta_lookup situations like the one MXRP presents.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.