[PD] [qlist] and locality

Alexandre Torres Porres porres at gmail.com
Thu Apr 3 21:13:38 CEST 2014


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 <jancsika at yahoo.com>:

> 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/aa82fa4d/attachment.htm>


More information about the Pd-list mailing list