----- Original Message ----- > From: Bill Gribble <[email protected]> > To: Jonathan Wilkes <[email protected]> > Cc: Lorenzo Sutton <[email protected]>; "[email protected]" > <[email protected]> > 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 <[email protected]> wrote: > >> >> >> >> >> ----- Original Message ----- >>> From: Bill Gribble <[email protected]> >>> To: Jonathan Wilkes <[email protected]> >>> Cc: Lorenzo Sutton <[email protected]>; > "[email protected]" <[email protected]> >>> 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 <[email protected]> >>>>> 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 >>> > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
