[DOCPATCH] BEGIN, CHECK, INIT, END explained more
Arthur Bergman
On Saturday, November 29, 2003, at 10:15 pm, Elizabeth Mattijsen wrote:
>
> $ perl -MO=Deparse -e 'BEGIN { foo => "bar" }'
> sub BEGIN {
> 'foo', 'bar';
> }
> -e syntax OK
>
> $ perl -MO=Deparse -e 'CLONE { foo => "bar" }'
> do {
> 'foo', 'bar'
> }->CLONE;
> -e syntax OK
>
Because CLONE/DESTROY are called on objects, the mere presence of them
does not affect the compilation.
Arthur
Ronald J Kimball
> --- pod/perlmod.pod.original Sat Nov 29 21:39:52 2003
> +++ pod/perlmod.pod Sat Nov 29 23:00:46 2003
> +A C<BEGIN> CODE block is executed as soon as possible, that is, the moment
> +it is completely defined, even before the rest of the containing file (or
> +string) is parsed. You may have multiple C<BEGIN> blocks within a file (or
> +string) -- they will execute in order of definition. Because a C<BEGIN>
I think 'string' here should be 'eval string' (or 'evaled string').
Otherwise someone may think BEGIN {} blocks are executed in any string.
> --- pod/perlsub.pod.original Sat Nov 29 22:12:17 2003
> +++ pod/perlsub.pod Sat Nov 29 22:50:01 2003
> @@ -202,13 +202,17 @@
> +The C<BEGIN>, C<CHECK>, C<INIT> and C<END> subroutines are not so much
> +subroutines as well as named magic CODE blocks, of which you can have more
I think 'as well as' should just be 'as'.
Ronald
Elizabeth Mattijsen
Hmmm... that statement as such is incorrect, I think. CLONE is
called as a _class_ method (I just realized), _not_ as an object
method. As the following shows:
use threads;
sub CLONE { warn "CLONE called with @_\n" }
threads->new( sub { 1 } )->join;
gives as output:
CLONE called with main
This is a point that should be made more clearly. I just realised
that after really grokking the "or inherited" in the following text
from perldelta.pod:
Support for the C<CLONE> special subroutine had been added.
With ithreads, when a new thread is created, all Perl data is cloned,
however non-Perl data cannot be cloned automatically. In C<CLONE> you
can do whatever you need to do, like for example handle the cloning of
non-Perl data, if necessary. C<CLONE> will be executed once for every
package that has it defined or inherited. It will be called in the
context of the new thread, so all modifications are made in the new area.
Boy, is that really hidden! Not so much the fact that it is called
as a class method, but that it is inherited. I always thought of
CLONE as a BEGIN, but I should have thought of CLONE as a DESTROY
(sort of). I never realized it was doing that. Must check my
Thread::xxx modules to see whether it all works as I though it did...
;-(
Liz
Arthur Bergman
On Sunday, November 30, 2003, at 12:40 am, Elizabeth Mattijsen wrote:
>> Because CLONE/DESTROY are called on objects, the mere presence of
>> them does not affect the compilation.
>
> Hmmm... that statement as such is incorrect, I think. CLONE is called
> as a _class_ method (I just realized), _not_ as an object method. As
> the following shows:
>
> use threads;
> sub CLONE { warn "CLONE called with @_\n" }
> threads->new( sub { 1 } )->join;
>
> gives as output:
>
> CLONE called with main
>
> This is a point that should be made more clearly. I just realised
> that after really grokking the "or inherited" in the following text
> from perldelta.pod:
>
Yes, sorry, meant called as methods when things happen.
Are there any more magic method names? :)
Arthur
Elizabeth Mattijsen
>On Sat, Nov 29, 2003 at 11:15:56PM +0100, Elizabeth Mattijsen wrote:
>
>> --- pod/perlmod.pod.original Sat Nov 29 21:39:52 2003
>> +++ pod/perlmod.pod Sat Nov 29 23:00:46 2003
>
>> +A C<BEGIN> CODE block is executed as soon as possible, that is, the moment
>> +it is completely defined, even before the rest of the containing file (or
>> +string) is parsed. You may have multiple C<BEGIN> blocks within a file (or
> > +string) -- they will execute in order of definition. Because a C<BEGIN>
>I think 'string' here should be 'eval string' (or 'evaled string').
>Otherwise someone may think BEGIN {} blocks are executed in any string.
Ok...I agree... I just wanted to add the fact that BEGIN blocks in
eval "" are also honoured: they don't need to reside in a file per se.
> > --- pod/perlsub.pod.original Sat Nov 29 22:12:17 2003
>> +++ pod/perlsub.pod Sat Nov 29 22:50:01 2003
>> @@ -202,13 +202,17 @@
>
>> +The C<BEGIN>, C<CHECK>, C<INIT> and C<END> subroutines are not so much
> > +subroutines as well as named magic CODE blocks, of which you can have more
>I think 'as well as' should just be 'as'.
I guess I should put my verbose mode to "off" ;-) Agreed.
Are those the only comments? "named magic CODE blocks" are a good
description for BEGIN, CHECK, INIT and END?
Liz
Tels
Moin,
On Saturday, November 29, 2003, at 10:15 pm, Elizabeth Mattijsen wrote:
>
> $ perl -MO=Deparse -e 'BEGIN { foo => "bar" }'
> sub BEGIN {
> 'foo', 'bar';
> }
> -e syntax OK
>
> $ perl -MO=Deparse -e 'CLONE { foo => "bar" }'
> do {
> 'foo', 'bar'
> }->CLONE;
> -e syntax OK
>
Arthur wrote:
>Because CLONE/DESTROY are called on objects, the mere presence of them
>does not affect the compilation.
Why is CLONE special, but FOO not? That doesn't follow from Liz' example:
te@null:~/perl/math/Math-BigInt-1.67> perl -MO=Deparse -e 'FOO { foo =>
"bar" }'
do {
'foo', 'bar'
}->FOO;
- -e syntax OK
te@null:~/perl/math/Math-BigInt-1.67> perl -MO=Deparse -e 'CLONE { foo =>
"bar" }'
do {
'foo', 'bar'
}->CLONE;
- -e syntax OK
Cheers,
Tels
- --
Signed on Sun Nov 30 15:49:37 2003 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"My name is Felicity Shagwell. Shagwell by name, shag very well by
reputation."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBP8oDtXcLPEOTuEwVAQFtYwf+O3bZ/UMQ1314ZqLWXsWCbE/U3neebcYG
jzsQF41Sr8AJmYkz9Ai2G4Z9sUP/oQ20N8F5TrKebzvCi9LBVwA3+3lD1NwNJ6zG
mqzF8tgK4fTZxosHdLcjBphzlDcrtJ+ZEHZ+jvhnrrlvmynK6EoBa4cK0IoAL1Ps
QYiP7LuUNqlHrey9Lb1V505piQy1UA66KPj4UtatQj6sad2gKhTbYqVO8Cr+G7Kz
79znAzAkBhjlQIQej6whoNVdISweQRbOg/ZK4ke691darp0yMeu7oWDQP85a0MsC
LjxJIblen8McxaJp6E1j3n73Q/c6UqEM+2g3orTHB5lbUQ0cQaVRPQ==
=oY6T
-----END PGP SIGNATURE-----
Elizabeth Mattijsen
> >Because CLONE/DESTROY are called on objects, the mere presence of them
> >does not affect the compilation.
>Why is CLONE special, but FOO not? That doesn't follow from Liz' example:
Actually, the CLONE _isn't_ special. Which is the source of the confusion.
BEGIN, CHECK, INIT and END are special as they don't need "sub"
All other capitalized subroutine names _do_ need the "sub", as they
are basically ordinary, explicitely callable subroutines that just
happen to be called by Perl depending on a number of triggers.
Liz
Enache Adrian
> Why is CLONE special, but FOO not? That doesn't follow from Liz' example:
>
> te@null:~/perl/math/Math-BigInt-1.67> perl -MO=Deparse -e 'FOO { foo =>
> "bar" }'
> do {
> 'foo', 'bar'
> }->FOO;
> - -e syntax OK
Deparse is wrong :-)
$ perl -e 'foo { bar => "baz" }'
Can't locate object method "foo" via package "bar" (perhaps you forgot to load "bar"?) at -e line 1.
$ perl -MO=Deparse -e 'foo { bar => "baz" }' | perl
-e syntax OK
Can't locate object method "foo" via package "baz" (perhaps you forgot to load "baz"?) at - line 1.
Or maybe Perl itself is wrong ?
Regards,
Adi
Nick Ing-Simmons
>
>Yes, sorry, meant called as methods when things happen.
>
>Are there any more magic method names? :)
tie has a whole list of "magic" method names ;-)
Elizabeth Mattijsen
And Perlio::via lists a lot also... Is there a comprehensive list of
these anywhere?
Liz
Jim Cromie
> A special section may need to be added later, to show that only BEGIN,
> CHECK, INIT and END don't need the "sub" prefix, and the other all
> uppercase subroutines _do_ need it (even if they don't generate any
> errors during compilation).
> .
1st, it may be wise to refer to these as "SPECIAL", not MAGIC,
since latter has a specific meaning in perl. Whether the specific
'magic' meaning should be reserved in perlmod.pod is a question
for the 'editor', as the audience is certainly broader than perlguts.
wrt classifying the specialness, these are the apparent critera;
whether theyre a useful or suboptimal taxonomy is something Ill learn
from following this thread ..
1. whether its callable by a user
BEGIN, END, CHECK, INIT are not.
btw, AUTOLOAD is callable directly, tho Im not sure it should be.
following example shows that a direct call gets a stale $AUTOLOAD.
DB<1> sub AUTOLOAD {print "foo\n"}
DB<2> joe()
foo
DB<5> sub AUTOLOAD {print "Auto: $AUTOLOAD @_\n"}
DB<8> $a = AUTOLOAD('bar')
Auto: main::joe bar
maybe it should be magically ;-) cleared by a goto &NAME or return.
Then again, it could be a 'dont do that then' type buglet.
CLONE() is callable, (assuming this test is valid)
but is meant/reserved for threading & multiplicity.
DB<1> sub CLONE {print "clone: @_\n"}
DB<2> $a = CLONE(1)
clone: 1
2. Whether its called magically by CORE on your behalf.
this is almost the opposite of 1, but for CLONE and AUTOLOAD
3. Whether theyre Methods or Functions.
tie methods are, duh, Methods.
those in 1 are Functions, except for AUTOLOAD, which should be
used as a method (authors choice though).
This criterion may not be important enough to draw here, since
they mostly go both ways.
4. whether theyre called by require, eval {}, eval ""
and whether theres a distinction within these - I think so..
As I (mis)? understand it, INIT and CHECK are only called at compilation
of main, (use time only). I thought this was confusing when I read it
(cant find a citation)
FWIW, BEGIN and END can be nested, though I dont know whether this
belongs in the begincheck example recently proposed in *, and added
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-11/msg00508.html
BEGIN {
print "first begin\n";
BEGIN {
print "first begin nested \n";
}
END {
print "nested end\n";
}
}
...
first begin nested
first begin
2 begin nested
2nd begin
begin nested in end
in main
1st end
If you think further additions along these lines are worthy in
begincheck, Ill do a patch.
If you think they belong in a separate init-check-require-eval example,
I can do that instead.
Elizabeth Mattijsen
>Elizabeth Mattijsen wrote:
>>A special section may need to be added later, to show that only
>>BEGIN, CHECK, INIT and END don't need the "sub" prefix, and the
>>other all uppercase subroutines _do_ need it (even if they don't
>>generate any errors during compilation).
>since latter has a specific meaning in perl. Whether the specific
>'magic' meaning should be reserved in perlmod.pod is a question
>for the 'editor', as the audience is certainly broader than perlguts.
I guess the magic is really in the parser than anything else... I
could live with SPECIAL as indeed MAGIC has a special annotation. By
the way, the original title of the section in perlmod.pod was:
Package Constructors and Destructors
which I though was an even more confusing description of BEGIN and END blocks.
>wrt classifying the specialness, these are the apparent critera;
>whether theyre a useful or suboptimal taxonomy is something Ill learn
>from following this thread ..
>1. whether its callable by a user
> BEGIN, END, CHECK, INIT are not.
Actually, they are, if you create a "real" subroutine with that name, e.g.
$ perl -e '*BEGIN = sub { warn "Hello world!\n" }; &BEGIN'
Hello world!
$
Again, the magic of BEGIN, CHECK, INIT and END is in the parsing and
the handling of the result of the parsing. After that, it's all
"normal"... ;-)
>btw, AUTOLOAD is callable directly, tho Im not sure it should be.
>following example shows that a direct call gets a stale $AUTOLOAD.
>
> DB<1> sub AUTOLOAD {print "foo\n"}
> DB<2> joe()
>foo
> DB<5> sub AUTOLOAD {print "Auto: $AUTOLOAD @_\n"}
> DB<8> $a = AUTOLOAD('bar')
>Auto: main::joe bar
>maybe it should be magically ;-) cleared by a goto &NAME or return.
>Then again, it could be a 'dont do that then' type buglet.
Not sure what you're doing here: the following shows that $AUTOLOAD
is not staled:
$ perl -e 'sub AUTOLOAD { warn "Hello world: $AUTOLOAD\n" };
$AUTOLOAD = 'foo'; &AUTOLOAD'
Hello world: foo
>CLONE() is callable, (assuming this test is valid)
>but is meant/reserved for threading & multiplicity.
> DB<1> sub CLONE {print "clone: @_\n"}
> DB<2> $a = CLONE(1)
>clone: 1
$ perl5.8.2-threaded -e 'sub CLONE { warn "Hello world!\n" }; &CLONE'
Hello world!
$ perl5.8.2-unthreaded -e 'sub CLONE { warn "Hello world!\n" }; &CLONE'
Hello world!
Just an ordinary sub, even in unthreaded Perls.
>2. Whether its called magically by CORE on your behalf.
>this is almost the opposite of 1, but for CLONE and AUTOLOAD
Well, I would put CLONE in the same class as the perltie special
subs, and the ones in PerlIO::via. It only gets called when you do a
threads->new, just as the tie methods get called if you do a tie().
>3. Whether theyre Methods or Functions.
>tie methods are, duh, Methods.
>those in 1 are Functions, except for AUTOLOAD, which should be
>used as a method (authors choice though).
>This criterion may not be important enough to draw here, since
>they mostly go both ways.
>
>4. whether theyre called by require, eval {}, eval ""
>and whether theres a distinction within these - I think so..
>As I (mis)? understand it, INIT and CHECK are only called at compilation
>of main, (use time only). I thought this was confusing when I read it
>(cant find a citation)
CHECK and INIT are only run after the initial "eval" (if you will) is
completed.
>FWIW, BEGIN and END can be nested, though I dont know whether this
>belongs in the begincheck example recently proposed in *, and added
>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-11/msg00508.html
Oops, missed that when it was posted. I think it is a nice example,
but I would point out that the number in the text, is actually the
ordinal number of the message as it will appear on the screen.
>BEGIN {
> print "first begin\n";
> BEGIN {
> print "first begin nested \n";
> }
> END {
> print "nested end\n";
> }
>}
>...
>
>first begin nested
>first begin
>2 begin nested
>2nd begin
>begin nested in end
>in main
>1st end
>
>If you think further additions along these lines are worthy in
>begincheck, Ill do a patch.
>If you think they belong in a separate init-check-require-eval
>example, I can do that instead.
I would think a whole seperate pod with a list of all uppercase
"subroutines", in which class they fall and when they are called,
would be nice to have. A sort of perlALLCAPS.pod ?
Liz
Yitzchak Scott-Thoennes
No, you are feeding it indirect object syntax ("method object") where
object is a BLOCK. Deparse is just showing it as the equivalent ->
method call.
Ronald J Kimball
But it's not equivalent; the error messages differ.
Ronald
Rafael Garcia-Suarez
> Having been bitten today by the fact that I can't call an INIT block
> by name (which is not documented as far as I know), I decided to take
> the bull by the horns and write some corrections and additional text
> in perlmod.pod and perlsub.pod.
>
> The most important thing about this patch, is that it introduces (I
> think) the term "named CODE blocks)" instead of "special subroutines"
> or "special functions". I also differentiated BEGIN, CHECK, INIT and
> END from the "other" all uppercase subroutines, as these are special.
Thanks, applied (with tweaks) as #21832.
I took the liberty to correct some errors, notably on the mechanism
behind O and B : this is not the CHECK block that stops the program, as
you wrote, and it's defined from inside an eval(""), whereas you stated
that CHECK/INIT blocks were ignored in eval("")s. (This eval happens
at compile-time when you load the O module, so it's OK.)
Elizabeth Mattijsen
>I took the liberty to correct some errors, notably on the mechanism
>behind O and B : this is not the CHECK block that stops the program, as
>you wrote, and it's defined from inside an eval(""), whereas you stated
>that CHECK/INIT blocks were ignored in eval("")s. (This eval happens
>at compile-time when you load the O module, so it's OK.)
Hmmm.... I believe you, the O and B modules are a bit messy...
So when _are_ CHECK/INIT blocks run then exactly? Is the definition
just as :they're only run once after compilation of the first outer
eval is completed?
Liz
Rafael Garcia-Suarez
CHECK and INIT blocks are run at the end of the compilation of the main
program. The fact that they were defined from inside an eval("") doesn't
matter. If the eval("") happened during the compilation of the main
program, they will be run. If it happened after the main program was
compiled, they will not.
Elizabeth Mattijsen
>Elizabeth Mattijsen wrote:
> > So when _are_ CHECK/INIT blocks run then exactly? Is the definition
>> just as :they're only run once after compilation of the first outer
> > eval is completed?
>CHECK and INIT blocks are run at the end of the compilation of the main
>program. The fact that they were defined from inside an eval("") doesn't
>matter. If the eval("") happened during the compilation of the main
>program, they will be run. If it happened after the main program was
>compiled, they will not.
That's what I meant to convey: what I call the "first outer eval" is
what you call "after the main program is compiled". I mean, I know
you can embed Perl within a C program: in that case you're don't
necessarily need to read a file to start up Perl, do you?
Liz
Arthur Bergman
On Wednesday, December 3, 2003, at 11:13 am, Elizabeth Mattijsen wrote:
>
> Hmmm.... I believe you, the O and B modules are a bit messy...
>
> So when _are_ CHECK/INIT blocks run then exactly? Is the definition
> just as :they're only run once after compilation of the first outer
> eval is completed?
>
>
>
Yes,
And this is IMHO a bug, they should be run whenever something is fully
compiled. As they stand they are utterly useless.
Arthur
Rafael Garcia-Suarez
>
> And this is IMHO a bug, they should be run whenever something is fully
> compiled. As they stand they are utterly useless.
Nope -- they are useful to exactly one and precisely defined thing : the
B:: modules. Every other use of CHECK/INIT is a bad hack.
What's needed IMO is yet another special code block -- COMPILED, START,
better names welcome -- run when the compilation of the said compilation
unit ends, regardless of the state of the main perl interpreter.
Arthur Bergman
On Wednesday, December 3, 2003, at 12:43 pm, Rafael Garcia-Suarez
wrote:
>
> Nope -- they are useful to exactly one and precisely defined thing :
> the
> B:: modules. Every other use of CHECK/INIT is a bad hack.
>
> What's needed IMO is yet another special code block -- COMPILED, START,
> better names welcome -- run when the compilation of the said
> compilation
> unit ends, regardless of the state of the main perl interpreter.
>
No I disagree, I want to know apply the B::module magic after I require
something runtime too.
I guess what we need is a hook that gets called whenever a compilation
of a outer lexical scope (file, eval"") is completed.
Arthur
Rafael Garcia-Suarez
> >
> > What's needed IMO is yet another special code block -- COMPILED, START,
> > better names welcome -- run when the compilation of the said
> > compilation
> > unit ends, regardless of the state of the main perl interpreter.
> >
>
> No I disagree, I want to know apply the B::module magic after I require
> something runtime too.
So write another B:: loader -- see below
> I guess what we need is a hook that gets called whenever a compilation
> of a outer lexical scope (file, eval"") is completed.
A START block, then. So
#!/usr/bin/perl
eval q{
BEGIN { print 1; }
START { print 2; }
CHECK { print 3; }
INIT { print 4; }
print 5;
END { print 6; }
};
print 7;
__END__
would print "12576".
You could then write an alternative to O.pm that loads B::* from
a START block instead of from a CHECK block. The whole CHECK magic
is entirely done in O -- there's no reason to stop poeple from using
B:: modules apart from the O framework.
Elizabeth Mattijsen
That could be done in a module, I think.
It's all a matter of how you would specify what needs to be run,
especially if you have multiple package in a single file. But
assuming you would require "Foo.pm", it would be easy to have a
Foo->REQUIRED routine run after the require was successful.
Just a matter of stealing CORE::require... ;-)
Liz