No subject

FTS_API void fts_atom_type_register(fts_symbol_t name, fts_class_t *cl);
FTS_API int fts_atom_type_lookup(fts_symbol_t name, fts_class_t **cl);

I don't know why PureData does not get added something like this.
(Miller -- this is a feature request.)

> > I am not sure, if relying on every foreign class ignoring unknown
> > atom type is a good idea.  If not, one could filter foreign
> > receivers, i.e. directly use outlet traversal routines, bypassing
> > the standard outlet_anything() mechanism.

Well, foreign classes either won't get the message, or else they most
probably are message-routing operations (eg: route, select, demux) in
which case the message's content is plainly put none of their business
(and so they have no business ignoring messages depending on their
contents either)

> > C-pointers around, like converting their hex representation into
> > either symbols (this could result in a Pd's symbol table lookup
> > slowdown),

if you mean converting full 8-byte hex codes into symbols, i call this
symbol table _flooding_. This is usually a not-nice thing to do, as it is
for all practical purposes a memory leak (symbols are forever). However if
that slows down PD's symbol table lookup, then that lookup function is
_badly_ _implemented_ and should be rewritten.

On Mon, 2 Sep 2002, Thomas Grill wrote:

> ... or you could divide a long integer into two short (16-Bit) ones which
> are exactly representable by two floats....
> also a bad hack.

Thank you. This is the bad hack I have coded, right before you sent me
this mail. Unfortunately for your taste, it works very well and there's no
other solution I know of. So much for calling things bad hacks.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju