[PD] [qlist] and locality

[Jonathan Wilkes]

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 at 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 at 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 at iem.at mailing list
>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140403/a5c67114/attachment-0001.htm>