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: