On Fri, Oct 05, 2007 at 10:30:03AM -0700, Allison Randal wrote:
> I'll work on this today, but if you want the quick fix, just call
> load_bytecode before newclass. (The quick fix won't work for your eval
> example.)
This is the workaround I'm using to get the PGE tests to pass,
but it's not always possible to do that. The use case I'm
looking at goes something like
load_bytecode 'PGE.pbc'
load_bytecode 'PGE/Dumper.pbc'
The PGE::Dumper module contains the methods needed to allow PGE::Match
to work with Data::Dumper. But in the above, by the time it is loaded,
the PGE::Match class has already been created by PGE.pbc .
We can switch the order of the load_bytecode steps above,
so that it reads
load_bytecode 'PGE/Dumper.pbc'
load_bytecode 'PGE.pbc'
This is a bit unnatural, but it works... as long as PGE::Dumper's
initialization routines don't need to do anything with the PGE::Match
class itself (or create any PGE::Match objects). To get around that
we could have PGE::Dumper do the load_bytecode of PGE.pbc... but
if we introduce a third module then we're really stuck.
-----
At any rate, pgc.pir and Perl6Grammar.pir (used to compile
grammars into PIR) both want the ability to compile and install rules
at runtime, so we really need the eval version to work before
we can progress much. Either that or I'll come up with a workaround
for those.
Thanks!
Pm
