[PD-dev] atom types: extend or abuse?

Krzysztof Czaja czaja at chopin.edu.pl
Wed Nov 12 14:03:28 CET 2003


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





More information about the Pd-dev mailing list