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