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)

2014-04-03 13:00 GMT-03:00 Jonathan Wilkes <jancsika@yahoo.com>:

On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014-04-03 03:05, Alexandre Torres Porres wrote:

[...]

btw: i would probably even recommend to use explicit *connections*
(rather than send/receive pairs) for anything local. then you never
have the problem of "[qlist] and locality" - very simple  and forces
you to think about your object interfaces.

I would also recommend only using global receive-symbols when you have to use them.  That way:
* your patches are more readable
* no need to feed $0 to message boxes
* when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language

-Jonathan

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z
FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK
ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX
GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT
6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW
lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe
bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs
CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy
WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r
FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa
zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h
JeTnSBV0Th0CjQER9Gik
=oC+u
-----END PGP SIGNATURE-----

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list