> On Sun, Jan 13, 2002 at 10:04:58PM +0100, Mattia Barbon wrote:
> > > $ bleadperl -MO=-qq,Deparse foo.plx
> > > sub BEGIN {
> > > print "foo\n";
> > > }
> > > print "bar\n";
> > >
> > > If B::Deparse can save BEGIN blocks, B::C can.
> >
> > I didn't mean that I can't write code to make B::C save BEGIN blocks
> > ( it'd require <10 lines, probably ), I did mean that doing so would
> > not be a god idea: _I am
> > saving the state of the program after those blocks were ran_ and
> > they will be run _another time_ at runtime, and this is not correct:
> > ( for example use lib 'a'; would put 'a' into @INC twice, once
> > ( correctly ) at compile time, and another time ( incorrectly ) at
> > runtime ). In this
> > case this is not harmful, but you get the idea.
>
> I don't understand. The compiled program should do exactly what the
> original program did. Anything else, as difficult as it may be, is a
> bug. Lots of programs and modules do important load-time checks and
> logic inside BEGIN blocks.
>
> Why would this:
>
> BEGIN {
> push @INC, 'foo';
> }
>
> put 'foo' into @INC twice if it were compiled? The compiled program
> should not be storing the post-BEGIN value of @INC, it should store
> the original value at startup.
This isn't the way B::C ( I suspect B::Bytecode and B::CC work
the same way ) works. It _by design_ saves the state _after_ the
BEGIB blocks are run; the idea is to skip compilation time.
Now, I know this is not going to always work, and the only ( always ) working
solution I see ( and I'd like to be proved wrong here ), is something like B::Script
( which stores the source code of the program+modules in a single executable ). And
yes, I realized that
[ B::C is not always going to work ] just a coule days ago.
Regards
Mattia
