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