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