IOhannes m zmoelnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
how will your [str] object handle an incoming gemlist?
If it's passed as a "string", a pointer to a block of bytes with a definite length, then it will process it the same way as any other block of bytes, perhaps not usefully.
right.
how will a gem-object using your blobs handle an incoming "string"?
It would need to verify that the incoming "string" data was of the right kind. Possibly the first few bytes would be some kind of selector. The data
right.
this is the problem i want to address. pd already has a typed atoms, why would one want to add atoms of "unknown" type and then implement an extra type-check in each and every object/library that introduces a new type.
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 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; 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".
Martin