Author: larry
Date: Thu Jan 3 19:42:19 2008
New Revision: 14480
Modified:
doc/trunk/design/syn/S09.pod
Log:
Typo from Smylers++
More clarification of assignment semantics in terms of underlying binding
Modified: doc/trunk/design/syn/S09.pod
==============================================================================
--- doc/trunk/design/syn/S09.pod (original)
+++ doc/trunk/design/syn/S09.pod Thu Jan 3 19:42:19 2008
@@ -1162,8 +1162,8 @@
Autovivification will only happen if the vivifiable path is bound to
a read-write container. Value extraction (that is, binding to a readonly
-or copy container) does not autovivify. (Note that assignment
-implicitly binds a copy, so it does not autovivify.) Any mention of
+or copy container) does not autovivify. (Note that assignment implicitly
+binds a copy, so it does not autovivify its right side.) Any mention of
an expression within a C<Capture> delays the autovivification decision
to binding time. (Binding to a "ref" parameter also defers the decision.)
@@ -1185,7 +1185,7 @@
my $val := %hash<foo><bar>;
my @array;
- my $cap = [EMAIL PROTECTED]; # $obj is a Capture object - see S02
+ my $cap = [EMAIL PROTECTED]; # $cap is a Capture object - see S02
my :($obj) := $cap; # @array[0][0] created here
my @array;
@@ -1237,4 +1237,8 @@
binds the left side to a mutable container, so it autovivifies.
+Assignment doesn't look like binding, but consider that it's really
+calling some kind of underlying set method on the container, which
+must be mutable in order to change its contents.
+
=for vim:set expandtab sw=4:
