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,
