thanks for explaining it all > 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
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you? As I don't see I'll be able to grasp the details for now, I'll just take your word for it :) cheers 2014-04-03 15:52 GMT-03:00 Jonathan Wilkes <[email protected]>: > 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 < > [email protected]> 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 <[email protected]>: > > 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----- > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list > > > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
