It seems that the way to handle this would be to replace $0 more directly:
1) keep symbols global by default 2) add technique for marking symbols as local, like [local foo]
By removing $0 you remove the part that makes it obvious that a given symbol is local. That seems like a bad tradeoff to me.
.hc
On Nov 16, 2012, at 1:21 AM, Jonathan Wilkes wrote:
Ok, I may have figured out a trick to get some scoping capability for "pd bound" symbol names, similar to the design Tim Blechmann described in his Nova pdf[1] (but probably a much hackier implementation).
- Make [declare] not complain when its initial args don't have a flag in front
of them, like [declare foo bar]. Also add a -global flag, (I'll explain later). 2) Possibly add a t_namelist to canvas's struct called "vars" or something (though there might be other ways to do this) that collects these initial args of [declare] 3) Add a convenience function called scope_symbol that takes a t_pd and a t_symbol "s", and does the following: a) compare "s" to the symbols in the vars namelist of the canvas that contains the object, b) if it's a match then prepend the canvas name ".xblah" to "s" and return it, and c) if it doesn't match go to the parent and repeat until you get to toplevel.
Now, at leisure revise code of objects that use pd_bind by putting scope_symbol immediately beforehand. For [receive], this is a single change. For [send] it's a bit trickier (I think you'd have to make the right inlet a proxy inlet in order to get it to work best).
Anyway, once those two (or any other) objects are revised in this way, they are backwards compatible with the way Pd currently makes everything global, but the new behavior can be utilized simply by typing the symbol as an initial argument to [declare] on the desired canvas. When mixing the old global behavior and the new, problems are unlikely to arise since the most common way of sharing patches is as abstractions, and generally the use of an abstraction doesn't require global variable interaction with the parent patch. In the rare case where conflicts do arise (and truly global variable needs are rare IMO), [declare -global foo] would revive the old behavior regardless of what's declared on the parents (i.e., an explicit declaration of global regardless of the declarations on the parent).
This is the best compromise I can think of to a) obsolete $0, b) provide an easy way for nested abstractions to communicate, and c) not break patches.
-Jonathan
[1] http://tim.klingt.org/publications/tim_blechmann_nova.pdf
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev