> With every object dumped I also dump its "id" (this is just its
> address, but any unique identifier will do).
I think the concept of the "externalized name" of an object that
persists is critical, but I *think* that "id" is a weak choice. For
my persistent objects, I need the object to persist across process
boundaries. As a result, an "id" (which currently corresponds to an
address in a single process space) suffers from a great risk of reuse.
In fact, even within a single process, if an object is saved off to a
persistent store, and memory reallocated, then "id" collisions are
*very* possible. It is also pretty critical (to garbage collection)
to realize *when* the externalized name has been captured. Note that
IF the name has not been extracted, then at process termination, there
is *no* reason to save (as the persistent object is unreachable!).
Hence it is very significant to distinguish when the "externalized
name" is captured (re: we must save) from when the id of an object is
taken (which happens all the time, and has no consequences in terms of
persistence). This last sentence is what motivated me to have a
*very* different method for getting a name of a persistent object. On
a lighter note, I admit that I actually call the GetID() method in my
implementation, so I understand the emotional motivation for thinking
of "id" as the name.... it is just that id() already has significant
distinct use and meaning to Python. Also note that "id()" has to be
fast, and the "GetID()" method *can* be slow, but it must be "right"
(a.k.a., totally unique within the persistent store).
...
There is a lot more stuff in the big posting, so see that for more
details ;-).
Jim