Author: larry Date: Fri Feb 8 12:15:28 2008 New Revision: 14503 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S04.pod
Log: There is no Undef type; it's either some kind of Object or some kind of Failure (or Whatever) Modified: doc/trunk/design/syn/S02.pod ============================================================================== --- doc/trunk/design/syn/S02.pod (original) +++ doc/trunk/design/syn/S02.pod Fri Feb 8 12:15:28 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 5 Feb 2008 + Last Modified: 8 Feb 2008 Number: 2 - Version: 127 + Version: 128 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -582,7 +582,7 @@ =item * Variables with non-native types can always contain I<undefined> values, -such as C<Undef>, C<Whatever> and C<Failure> objects. See S04 for more +such as C<Object>, C<Whatever> and C<Failure> objects. See S04 for more about failures (i.e. unthrown exceptions): my Int $x = undef; # works @@ -856,13 +856,21 @@ built-in C<undef> and C<fail> functions. (See S04 for how failures are handled.) - Undef Undefined (variants serve as prototype objects of classes) + Object Uninitialized (derivatives serve as protoobjects of classes) Whatever Wildcard (like undef, but subject to do-what-I-mean via MMD) Failure Failure (lazy exceptions, thrown if not handled properly) Whenever you declare any kind of type, class, module, or package, you're automatically declaring a undefined prototype value with the same name. +Whenever a C<Failure> value is put into a typed container, it takes +on the type specified by the container but continues to carry the +C<Failure> role. (The C<undef> function merely returns the most +generic C<Failure> object. Use C<fail> to more specific failures. Use +C<Object> for the most generic non-failure undefined value. The C<Any> +type is also undefined, but excludes C<Junctions> so that autothreading +may be dispatched using normal multiple dispatch rules.) + =head2 Immutable types Objects with these types behave like values, i.e. C<$x === $y> is true Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Fri Feb 8 12:15:28 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 19 Aug 2004 - Last Modified: 22 Jan 2008 + Last Modified: 8 Feb 2008 Number: 4 - Version: 63 + Version: 64 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -900,10 +900,16 @@ C<Failure> objects, any of which refers to an unthrown C<Exception> object in C<$!> and knows whether it has been handled or not. -If you test a C<Failure> for C<.defined> or C<.true>, it causes -C<$!> to mark the exception as I<handled>, and acts as a harmless C<Undef> -value thereafter. Any other use of the C<Failure> will throw its associated -exception immediately. +If you test a C<Failure> for C<.defined> or C<.true>, it causes C<$!> +to mark the exception as I<handled>; the exception acts as a relatively harmless +undefined value thereafter. Any other use of the C<Failure> object to +extract a normal value will throw its associated exception immediately. +(The C<Failure> may, however, be stored in any container whose type +allows the C<Failure> role to be mixed in.) The C<.handled> method +returns false on failures that have not been handled. It returns true for +handled exceptions and for every other kind of object. (That is, +it is an C<Object> method, not a C<Failure> method. Only C<Failure> objects +need to store the actual status however; other types just return C<True>.) Because the contextual variable C<$!> contains all exceptions collected in the current lexical scope, saying C<die $!> will throw all exceptions,