----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Monday, November 19, 2012 2:35 PM Subject: Re: [PD-dev] may have figured out scope
It seems that the way to handle this would be to replace $0 more directly:
- keep symbols global by default
That's what I said below.
- add technique for marking symbols as local, like [local foo]
What does [local foo] do different than [declare foo]? I assume with your approach you miss out on the feature of Tim's design that let's you declare foo for the parent and have the child communicate with it (something you can only do currently by passing $0 as an abstraction arg which is ugly and cumbersome). (Otherwise it would sound like exactly the same design I proposed.)
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.
I'm not removing $0-- as I said my solution is backwards compatible. Replace canvas name ".xblah" with "$0" in what I wrote and it works exactly the same.
One more question that applies to any system of scoping-- how do you apply it to the message box? I forgot about that aspect when I wrote the OP.
-Jonathan
.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).
- 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