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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
