Author: lwall Date: 2010-07-09 23:10:45 +0200 (Fri, 09 Jul 2010) New Revision: 31601
Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] simplify definition of successful return to be context agnostic define class-level PRE/POST to be submethods that are called like BUILD/DESTROY Modified: docs/Perl6/Spec/S04-control.pod =================================================================== --- docs/Perl6/Spec/S04-control.pod 2010-07-09 19:47:34 UTC (rev 31600) +++ docs/Perl6/Spec/S04-control.pod 2010-07-09 21:10:45 UTC (rev 31601) @@ -13,8 +13,8 @@ Created: 19 Aug 2004 - Last Modified: 27 Apr 2010 - Version: 98 + Last Modified: 9 Jul 2010 + Version: 99 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -1342,7 +1342,8 @@ their side effects. C<PRE> and C<POST> must return boolean values that are evaluated according to the usual Design by Contract (DBC) rules. (Plus, if you use C<ENTER>/C<LEAVE> in a class block, they only execute when the -class block is executed, but C<PRE>/C<POST> in a class block are evaluated +class block is executed, but you may declare C<PRE>/C<POST> submethods +in a class block that will be evaluated around every method in the class.) C<KEEP> and C<UNDO> are just variants of C<LEAVE>, and for execution order are treated as part of the queue of C<LEAVE> phasers. @@ -1376,8 +1377,19 @@ everything else, to guarantee that even C<LEAVE> phasers can't violate DBC. Likewise C<PRE> phasers fire off before any C<ENTER> or C<FIRST> (though not before C<BEGIN>, C<CHECK>, or C<INIT>, since those are done at compile or -process initialization time). +process initialization time). Much like C<BUILD> and C<DESTROY> are implicitly +called in the correct order by C<BUILDALL> and C<DESTROYALL>, the C<PRE>/C<POST> +calls are via an implicit C<ENFORCEALL> method that runs +outside the actual call to the method in question. Class-level C<PRE>/C<POST> +submethods are notionally outside of the method-level C<PRE>/C<POST> blocks. +At each submethod level, C<ENFORCEALL> calls (in the normal course of things): + 1. class's C<PRE> submethod + 2. method's C<PRE> phaser + 3. method call + 4. method's C<POST> phaser + 5. class's C<POST> submethod + If exit phasers are running as a result of a stack unwind initiated by an exception, C<$!> contains the exception that caused it, though it will be marked as handled by then. In any case, the information @@ -1404,11 +1416,15 @@ world in raw form, so that the phaser doesn't accidentally impose context prematurely.) -The topic of the outer block is still available as C<< OUTER::<$_> >>. +The topic of the outer block of a phaser is still available as C<< OUTER::<$_> >>. Whether the return value is modifiable may be a policy of the phaser in question. In particular, the return value should not be modified within a C<POST> phaser, but a C<LEAVE> phaser could be more liberal. +Class-level C<PRE> and C<POST> submethods are not in the lexical +scope of a method, and are not run in the dynamic scope of the method, +so cannot see the method's C<$_> at all. + =head1 Statement parsing In this statement: @@ -1578,14 +1594,7 @@ is okay. In the absence of error exception propagation, a successful exit is one that -returns a defined value in item context, or any number of values -in list context as long as the length is defined. (A length of +Inf -is considered a defined length. A length of 0 is also a defined length, -which means it's a "successful" return even though the list would evaluate -to false in a boolean context.) A list can have a defined length -even if it contains undefined scalar values. A list is of undefined -length only if it contains an undefined generator, which, happily, is -what is returned by the C<fail> function when used in list context. +returns a defined value or parcel. (A defined parcel may contain undefined values.) So any PerlĀ 6 function can say fail "message";