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). > > 1) 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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
