hi Miller, thanks so much for your comments,
Miller Puckette wrote: ...
3b. Indices into a pool (pdp). In order to make validation
...
I think 3a isn't really safe. I don't understand why 3b requires anything extra (you can just interpret numbers as indices and let it just be wrong if someone gives you a wrong number.) These _is_
I am confusing things for sure. In general terms, testing that a reference is valid (that a referenced party exists), is one thing, while another thing is testing that what I have is actually a reference, and a proper type of a reference.
Thinking in general terms is mind-boggling, so I am thinking by examples. In a reference-counting scheme currently used in plustot, one can safely assume a reference is valid, after successful testing for type compatibility. This is because a referenced object itself (not a stub) has its refcount incremented when a fake-symbol is being created. The fake-symbol has a refcount too, btw, in order to make sure Pd objects may safely toss it around.
So, in this case, reference validation and type compatibility is the same thing. However, this is a case, in which refcount-controlled object destruction does actually make sense. There are other cases, of course.
For example, the gpointer scheme is different. Glist may be gone, but there is a stub maintained until no reference points there. Thus both tests are needed: is an atom a gpointer, and does it point to an existing glist. (In fact, since glist-type of a gpointer points to glist elements, not to a glist as a whole, there is yet another test needed, for freshness, although it is glist-specific, and not required for other types of a pointee.)
Now, it looks like the gpointer method is more general...
Krzysztof