Author: lwall
Date: 2010-04-05 18:47:42 +0200 (Mon, 05 Apr 2010)
New Revision: 30315

Modified:
   docs/Perl6/Spec/S02-bits.pod
Log:
[S02] clarify that object identity from WHICH may not be a mundane value type


Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
--- docs/Perl6/Spec/S02-bits.pod        2010-04-05 14:02:52 UTC (rev 30314)
+++ docs/Perl6/Spec/S02-bits.pod        2010-04-05 16:47:42 UTC (rev 30315)
@@ -13,8 +13,8 @@
 
     Created: 10 Aug 2004
 
-    Last Modified: 30 Mar 2010
-    Version: 210
+    Last Modified: 5 Apr 2010
+    Version: 211
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -576,10 +576,40 @@
 Some object types can behave as value types.  Every object can produce
 a "WHICH" value that uniquely identifies the
 object for hashing and other value-based comparisons.  Normal objects
-just use their address in memory, but if a class wishes to behave as a
+just use their location as their identity, but if a class wishes to behave as a
 value type, it can define a C<.WHICH> method that makes different objects
 look like the same object if they happen to have the same contents.
 
+When we say that a normal object uses its location as its identity,
+we do I<not> mean that it returns its address as a number.  In the first
+place, not all objects are in the same memory space (see the literature
+on NUMA, for instance), and two objects should not accidentally have
+the same identity merely because they were stored at the same offset in
+two different memory spaces.  We also do not want to allow accidental
+identity collisions with values that really are numbers (or strings,
+or any other mundane value type).  Nor should we be encouraging people
+to think of object locations that way in any case.  So C<WHICH> still
+returns a value rather than another object, but that value must be of
+a special C<ObjID> type that prevents accidental confusion with normal
+value types, and at least discourages trivial pointer arithmetic.
+
+Certainly, it is difficult to give a unique name to every possible
+address space, let alone every possible address within every such
+a space.  In the absence of a universal naming scheme, it can only
+be made improbable that two addresses from two different spaces will
+collide.  A sufficently large random number may represent the current
+address space on output of an C<ObjID> to a different address space,
+or if serialized to YAML or XML.  (This extra identity component
+need not be output for debugging messages that assume the current
+address space, since it will be the same big number consistently,
+unless your process really is running under a NUMA.)
+
+Alternately, if an object is being serialized to a form that does
+not preserve object identity, there is no requirement to preserve
+uniqueness, since the object is in this case is really being translated
+to a value type representation, and reconstituted on the other end
+as a different unique object.
+
 =item *
 
 Variables with non-native types can always contain I<undefined> values,

Reply via email to