IOhannes m zmölnig wrote: > 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 > > Sure! I did the string/blob as a first attempt to see if it could be done. I'd be quite happy to see it done better.
>> 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. > > Well because A_BLOB is the type that can be anything, and blob_type is the particular type. The pd core needs to be patched for every new A_THING, but externals could handle the different blob_types without passing through the core. The A_BLOB handler just calls the user-defined function for its own blobs, or a default when there is none. Probably it's unnecessary to have the blob_type registered in the core as long as pd passes A_BLOB messages around properly. I was thinking that the class_addmethod function needed the s_blob symbol but it probably would work without it. > >> 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. > Whatever it is has to be 8 bytes long and contain a pointer to something (4 bytes) as well as a way to know what kind of thing the data is. It could be an int or a pointer to a symbol or something else. > 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. > > Maybe something like: typedef struct _blob /* pointer to a blob */ { int s_guid; /* unique identifier for this type of blob */ void *s_data; /* pointer to 1st byte of blob */ } t_blob; Then an external would ignore blobs with guids it doesn't recognize. The s_data for a "string" would be defined inside the str external as: typedef struct _string_blob /* pointer to a string blob */ { unsigned long str_length; /* length of string in bytes */ unsigned char *str_data; /* pointer to 1st byte of string */ } string_blob; and if you had a t_blob pointer b it would access the first byte of the string as ((string_blob *)(b->s_data))->str_data[0] Martin _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev