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.
There could also be a totally Pd-ish string library too.
No idea what that means in your head, sorry... :/
And I still don't know what that means, sorry again. :(
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec