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