For example, if you have two help patches open and each has an array inside it named "array1". One of the help patches will work, and the other won't. That's because
"Put" menu arrays assume you only have one array by that name. Pd will use the first one it finds (probably the first one you create) and the duplicate will be ignored.
In the case of arrays you'll get a warning, because you're not supposed to use the same name twice. But with the send/receive classes (as well as many
other objects that use pd_bind) you can have many s/r pairs sharing the same name.
So suppose you have [s loop] and [r loop] in a subpatch, and [s loop] and [r loop] in an unrelated subpatch.
Are those s/r pairs supposed to communicate with each other? Or...
Did the author forget he/she already used the name "loop" for the first s/r pair and
doesn't actually want the other s/r pair to
communicate with the first?
If the answer to the second question is yes, then that's an example of a nameclash. Pd doesn't give you a way to tell the difference. Most programming languages have clear and sensible ways to avoid this. There's even a Pd external to do it-- I think it's called
[sendlocal] and [receivelocal]-- but its
author erroneously thought that $0 deprecates those objects.
Pd gurus on the list can give you seemingly simple workarounds for these problems with scope and nameclashes, but as you the programmer accumulate them it gets more and more unwieldy. Worse, it makes it difficult to read patches, as you must spend
time decoding someone else's idiosyncratic use of [makefilename] or whatever they are doing to get Pd to do what is concise, consistent and robust in nearly every other modern programming language.
Finally-- and again-- these problems cannot be improved in Pd without breaking some backwards compatibility.
Just take the related issue of namespaces with external libraries-- it's hard enough to design and test something robust like Python's namespacing. Now imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible, and that means as long as people imagine Pd Vanilla as the "core" Pd $0 hackery is the only way to simulate scoping.
-Jonathan
On Thursday, April 3, 2014 12:35 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
> * when you run into nameclashes, you know your project > has outgrown Pd and it's time to choose another
language
what's a nameclash? (maybe I haven't outgrown Pd yet)