Author: lwall
Date: 2010-07-09 23:10:45 +0200 (Fri, 09 Jul 2010)
New Revision: 31601

[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 
+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 
 So any PerlĀ 6 function can say
     fail "message";

Reply via email to