view release on metacpan or  search on metacpan

perloptree.pod  view on Meta::CPAN

  pushmark
    args ...
  gv => subname
  entersub

=head2 Call a method

Here we have several combinations to define the package and the method name, either
compile-time (static as constant string), or dynamic as B<GV> (for the method name) or 
B<PADSV> (package name).

B<method_named> holds the method name as C<sv> if known at compile time.
If not B<gv> (of the name) and B<method> is used.
The package name is at the top of the stack.
A call stack is added with B<pushmark>.

1. Static compile time package ("class") and method:

Class->subname(args...) =>

  pushmark
  const => PV "Class"
    args ...
  method_named => PV "subname"
  entersub

2. Run-time package ("object") and compile-time method:

$obj->meth(args...) =>

  pushmark
  padsv => GV *packagename
    args ...
  method_named => PV "meth"
  entersub

3. Run-time package and run-time method:

$obj->$meth(args...) =>

  pushmark
  padsv => GV *packagename
    args ...
  gvsv => GV *meth
  method
  entersub

4. Compile-time package ("class") and run-time method:

Class->$meth(args...) =>

  pushmark
  const => PV "Class"
    args ...
  gvsv => GV *meth
  method
  entersub

=head1 Hooks

=head2 Special execution blocks BEGIN, CHECK, UNITCHECK, INIT, END

Perl keeps special arrays of subroutines that are executed at the
beginning and at the end of a running Perl program and its program
units. These subroutines correspond to the special code blocks:
C<BEGIN>, C<CHECK>, C<UNITCHECK>, C<INIT> and C<END>. (See basics at
L<perlmod/basics>.)

Such arrays belong to Perl's internals that you're not supposed to
see. Entries in these arrays get consumed by the interpreter as it
enters distinct compilation phases, triggered by statements like
C<require>, C<use>, C<do>, C<eval>, etc.  To play as safest as
possible, the only allowed operations are to add entries to the start
and to the end of these arrays.

BEGIN, UNITCHECK and INIT are FIFO (first-in, first-out) blocks while
CHECK and END are LIFO (last-in, first-out).

L<Devel::Hook> allows adding code the start or end of these
blocks. L<Manip::END> even tries to remove certain entries.

=head3 The BEGIN block

A special array of code at C<PL_beginav>, that is executed before
C<main_start>, the first op, which is defined be called C<ENTER>.
E.g. C<use module;> adds its require and importer code into the BEGIN
block.

=head3 The CHECK block

The B compiler starting block at C<PL_checkav>. This hooks int the
check function which is executed for every op created in bottom-up,
basic order.

=head3 The UNITCHECK block

A new block since Perl 5.10 at C<PL_unitcheckav> runs right after the
CHECK block, to seperate possible B compilation hooks from other
checks.

=head3 The INIT block

At C<PL_initav>.

=head3 The END block

At C<PL_endav>.

L<Manip::END> started to mess around with this block.

The array contains an C<undef> for each block that has been
encountered. It's not really an C<undef> though, it's a kind of raw
coderef that's not wrapped in a scalar ref. This leads to funky error
messages like C<Bizarre copy of CODE in sassign> when you try to assign
one of these values to another variable. See L<Manip::END> how to
manipulate these values array.

=head2 B and O module. The perl compiler.

Malcom Beattie's B modules hooked into the early op tree stages to
represent the internal ops as perl objects and added the perl compiler
backends. See L<B> and L<perlcompile>.

The three main compiler backends are still B<Bytecode>, B<C> and B<CC>.

I<Todo: Describe B's object representation a little bit deeper, its
CHECK hook, its internal transformers for Bytecode (asm and vars) and
C (the sections).>

=head2 MAD

MAD stands for "Misc Attributed Data".

Larry Wall worked on a new MAD compiler backend outside of the B
approach, dumping the internal op tree representation as B<XML> or
B<YAML>, not as tree of perl B objects.

The idea is that all the information needed to recreate the original source is
stored in the op tree. To do this the tokens for the ops are associated with ops,
these madprops are a list of key-value pairs, where the key is a character as
listed at the end of F<op.h>, the value normally is a string, but it might also be
a op, as in the case of a optimized op ('O'). Special for the whitespace key '_'
(whitespace before) and '#' (whitespace after), which indicate the whitespace or
comment before/after the previous key-value pair.

Also when things normally compiled out, like a BEGIN block, which normally do
not results in any ops, instead create a NULLOP with madprops used to recreate
the object.

I<Is there any documentation on this?>

Why this awful XML and not the rich tree of perl objects?

Well there's an advantage.
The MAD XML can be seen as some kind of XML Storable/Freeze of the B