IOhannes m zmoelnig wrote: > Martin Peach wrote: > >> IOhannes m zmoelnig wrote: >> >>> the [text3d]... objects expect a "string" message with pdstrings >>> (according to moocows stuff). >>> >> OK, so the message [string( is being interpreted by pd as a selector for >> A_STRING instead of just a message "string", because "string" has become a >> reserved word. >> > > correct. > > my proposal is therefore to entirely skip reserved words when > introducing new types and solely rely on the atom-type (A_BLOB), rather > than the list selector. > > Fair enough, but that would mean changing the pd API, for instance the class_addmethod function, which wants a selector. Pd seems to use the type A_BLOB in some places and the selector s_blob in others, I'm not sure if it could be made to use only the type without breaking all the currently existing externals.
> do you have any strong reason why you need to reserve a selector when > introducing a new atom-type? > (apart from: "that was the way it seemed to be done") > That's right. I basically copied the way it was done for floats and lists. I tried not using a selector but things didn't work properly, like class_addmethod. If you can see how it could be made to work without the selector, please let us know. > >>> your string-patch adds a special message "string" for your strings. >>> i think that is where the problem comes in: A_GIMME != A_STRING >>> >>> >> The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. >> Does this resolve the issue? Or will it cause [blob( messages to go wrong? >> > > the problem is not with A_BLOB vs A_STRING, but with use of selectors. > see above. True, I forgot to mention that I also changed the "string" selector to "blob". Martin _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
