Author: larry
Date: Sat Apr 28 15:23:15 2007
New Revision: 14389

Modified:
   doc/trunk/design/syn/S12.pod

Log:
Use of protoobjects for role initial values.


Modified: doc/trunk/design/syn/S12.pod
==============================================================================
--- doc/trunk/design/syn/S12.pod        (original)
+++ doc/trunk/design/syn/S12.pod        Sat Apr 28 15:23:15 2007
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 27 Oct 2004
-  Last Modified: 27 Apr 2007
+  Last Modified: 28 Apr 2007
   Number: 12
-  Version: 48
+  Version: 49
 
 =head1 Overview
 
@@ -1898,17 +1898,32 @@
 
     Dog{ :name<Fido> }
 
-This is still lazily evaluated:
+This form is also lazily evaluated:
 
     my $dog = Dog{ :name<Fido> };
     defined $dog or say "doesn't exist";  # Fido doesn't exist
     $dog.wag()                            # Fido wags his tail
 
-Note that when used as an argument to a method like C<bless>, the
-protoobject is sufficiently lazy that autovivifying is done only by
-the appropriate C<BUILD> routine.  It does not waste energy creating
-a C<Dog> object when that object's attributes would later have to be
-copied into the actual object.
+When the typename happens to be a role, autovivifying it involves
+attempting to create a punned class of the same name as the role.
+Whether this succeeds or not depends on whether the role is
+sufficiently complete to serve as a class on its own.  Regardless of
+whether such an attempt would succeed, it is always perfectly fine to
+define a lazy protoobject for a role just as long as it's only ever
+used as an argument to C<bless>, since C<bless> will only be using
+its closure to construct the role's C<BUILD> arguments in the context
+of the complete new class.  (Of course, an inconsistent or incomplete
+class composition may subsequently fail, and in fact the incomplete
+role autovivification mentioned above is likely to be implemented by
+failing at the point of class composition.)
+
+Note that when used as an argument to a method like C<bless>,
+the protoobject is sufficiently lazy that autovivifying is done
+only by the appropriate C<BUILD> routine.  It does not waste energy
+creating a C<Dog> object when that object's attributes would later
+have to be copied into the actual object.  (On top of which, such
+an implementation would make it impossible to use protoobjects to
+initialize incomplete roles.)
 
 The object autovivification syntax works only for literal named types,
 so any indirection must be written more explicitly:

Reply via email to