Skip Menu |

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 71922
Status: new
Priority: 0/
Queue: Moose

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

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



Subject: constants are always detected as methods
From the mailing list: I think this is actually a bug in our method detection heuristics - perl optimized constants to not be "real" subroutines, and so they don't track information about their definition in the same way other subroutines do. I'll see if I can come up with a fix. In the meantime, you can work around this issue by adding "__PACKAGE__->can('TRUE'); __PACKAGE__->can('FALSE')" to Constants.pm - this should prevent them from being "actual" constants, and so Moose should be able to deal with them properly. From IRC: 14:53 <@doy> hmmm, that constants issue is an interesting one 14:53 <@doy> (possibly, i haven't actually looked into it yet) 14:55 <@doy> i wonder if they aren't expanded into full cvs until we actually poke at them, and by that point they're in the right package, so we assume they're methods 14:57 <@doy> i think that is what's happening 15:11 <@rjbs> "full CVS" 15:14 <@autarch> we're switching to CVS? awesome 15:25 <@rafl> we should be calling gv_init on all globs we poke at 15:25 <@rafl> so all constant subs in there should be inflated to full CVs, i believe 15:26 <@doy> yeah, we need to stop doing that so much i think 15:26 <@doy> or something 15:26 <@doy> actaully i'm not sure 15:27 <@rafl> we should stop doing that to not destroy optimisations anymore 15:27 <@doy> is there a difference between a constant sub declared in a package and a constant sub imported from another package, if they aren't inflated until they're in the final package? 15:27 <@rafl> but not having full GVs with CVs in them seems like an unlikely source of bugs right now 15:27 <@doy> well yeah, that too 15:28 <@rafl> no idea about that question 15:28 <@doy> hmmm 15:28 <@doy> in most places it doesn't matter i think 15:28 <@doy> because in most places we're only dealing with methods 15:29 <@doy> and those being constants doesn't make much sense 15:29 <@doy> but in the code where we're determining if something is a method or not 15:29 <@doy> it might matter there 15:30 <@doy> i think we're just looping over all code symbols in the package, inflating them to CVs, and then asking those what package they were defined in 15:30 <@doy> which is less than ideal 15:30 <@rafl> ask obra about the constant method thing 15:30 <@rafl> i remember Prophet or SD being full of use constant TYPE => 'foo' 15:31 <@rafl> err. type => 'FOO' 15:31 <@doy> i'll poke around at the code a bit first 15:31 <@rafl> mm