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,