----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 10:05 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
T he case you describe is the easy one, once you introduce any kind of lexical hygiene. Names in use in a patch bind closely to the patch or scope in which they are used, so there's no danger of escapes from a patch just because its being used within another patch.
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in the same patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I think you have to have a way to explicitly state that "binding symbol foo applies to >this< canvas and all of its children, but not to any parents". Do you have a way to do that without using the $0 kludge?
There are also use cases for "binding symbol foo applies to all instances of
this< abstraction", and possibly "all instances of abstractions from >this<
libdir" (though the latter may be overkill).
-Jonathan
At the same time, references to names that can't be resolved in the local scope do bubble up, so you can have more global names if you need them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com I am working on a pd-clone intended to explore a lot of the
topics in
this
thread. It's not fully baked yet -- the biggest working
patch is
a biquad
filter designer with pole-zero and freq response plotting --
but
I'm
particularly excited about the approach to namespacing and
scope
management,
which works a lot like hc describes. Patches have a set of
scopes
which can be
mapped onto subpatches (represented as layers, not separate
windows).
Name
resolution in send/receive elements works like you would want
it to.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the
tree
of patches and scopes is crawled upward from the site of the lookup.
For
example, the (equivalent of) [s "foo"] first looks in the
scope of the
[s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to
find an
object named "foo", then find "bar" in its
patch-global
scope (or an object named "bar" within a scope named "foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want to share
my abstraction
with Bob who needn't worry about the send/receive names I used inside
[blah]
because they are guaranteed not to conflict with anything he does outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble