[PD-dev] gem vs. mrpeach strings?

[Martin Peach]

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