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: