Martin Peach wrote: > IOhannes m zmoelnig wrote: >> >> > I suppose because the surgery required to add a type to pd is not easy, > and requires patching the source, so just adding a single 'unknown' type > that requires the external to do the type-checking is easier. If the
why? when patching the core is needed (which i agree that it is), then we could just go the whole length > atoms were not restricted in size it would be easy to just add another > field to identify the type. The way things are it might be better to > modify the blob type > from: > typedef struct _blob /* pointer to a blob */ > { > unsigned long s_length; /* length of blob in bytes */ > unsigned char *s_data; /* pointer to 1st byte of blob */ > } t_blob; > > to: > typedef struct _blob /* pointer to a blob */ > { > t_symbol *blob_type; > void *blob; /* pointer to blob */ > } t_blob; still i don't understand why you would want a blob to have 2 types: A_BLOB and blob_type. iirc, atom.a_type is (int), which gives us a huge wealth of possible types and no need to add another type-system. > then after verifying that the blob_type is the right one, the blob could > be accessed according to its expected structure. In the case of string > blobs the blob type would be "string" and the blob itself would be a > struct consisting of the length and the pointer to the data. You still > have the problem of name conflicts, just as with the different "counter" > objects, but there is no way of avoiding that in every case, apart from > having a central repository of registered names or a dispenser of > "globally unique identifiers". i think this could be solved if you don't insist on giving a symbolic name, and have a way to share a variable across your objects. furthermore, even with names, the good news is, that you can chose an arbitrary name (which nobody but the C-programmer has to remember), which is a lot easier than with object-names. for instance, one could (by convention), use globally unique identifiers. fgmads.r IOhannes _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev