[PD-dev] removing string types from pd-extended release

[IOhannes m zmölnig]

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