Martin Peach wrote:
I've attached the reasoning behind my string patch, probably there is a lot wrong with it.
But I can't see how to do this kind of thing otherwise without modifying Pd.
i only proposed to just removed all the selector stuff ("string") and use plain atoms (within lists/messages) instead.
i don't see _any_ reason why we would need to have a "stringmethod" pd knows about. instead use:
<snip> #define STRING_ATOMID=666 static void myobj_string(t_myobj*x, t_symbol*s, int argc, t_atom*argv) { if (argc && STRING_ATOMID==argv->a_type) { // hold on, this is a string! ... } else { pd_error(x, "expected string"); } }
void myobj_setup(void) { ... class_addmethod(myobj_class, (t_method)myobj_string, gensym("string"), A_GIMME, 0); } </snip>
et voila! no need to patch Pd at all.
in a second step, Pd should handle atoms outside its "known" world properly. my initial idea was to introduce a way to register new types with Pd, so pd would know about a new a_type number during runtime and would be able to do handle it more intelligently (e.g. calling a certain atom_getstring() method when [post]ing; rejecting atom-types that it doesn't know about;...)
miller was rather reluctant about this, as it probably adds too much hazzle for too little benefit. therefore we basically agreed (at lac2008) that we would just use additional a_type-numbers and that's basically it!
fgmadsr IOhannes