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