Mathieu Bouchard wrote: > On Thu, 5 Mar 2009, Hans-Christoph Steiner wrote: >> On Mar 5, 2009, at 11:14 AM, Mathieu Bouchard wrote: >>> I very much recommend making a library that can handle both at an >>> expense that is as close as possible to making a library for just one >>> of them. >>> But I believe that those list abstractions should be made for lists, >>> and not for anythings, which is a dangerous precedent set by [list], >>> because for example it prevents introducing a message "array $1" >>> where $1 would be a send-symbol for an array. (Or it could be called >>> [table]. why are there two names for that concept in pd anyway?) >> I think that [array $1( would be better represented by an argument and >> a matching inlet. I think that's clearer than using [array $1(. > > I've never seen an object have two different hot inlets doing the same > thing for different types and two different cold inlets doing the same > thing for different types. This is probably not what you mean, and if > it's not, then you have to know that I'm talking about making classes > that each can support both lists and array-names for each of the > arguments to an operation. This is what I am talking about, and not > about classes that support just arrays. >
Yes it seems to me a string manipulation object like [strncmp] should be able to accept symbols, floats, lists of floats, and messages naming arrays, on any of its inlets that are meant to accept strings. Maybe it should be [arrble $1( or [tabray $1( so as not to prefer one over the other. Martin _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
