[L2Ork-dev] Patch private abstractions

[Jonathan Wilkes]

On Mon, Aug 17, 2020 at 6:47 AM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
>
> Hi,
>
> The following approach, suggested by Matt, is the source of the current implementation:
>
> > 1. [ab <name>] abstractions are treated as every bit as local as [pd
> > <name>] subpatches, except for each instance has a private $0. [ab <name>]
> > definitions do not cross file boundaries, either up to parent or down to
> > file abstractions, but the can cross [ab <name>] boundaries, so that [ab
> > lob] first defined as root->[pd foo]->[ab bar]->[ab lob] can be
> > instantiated anywhere else in root except in another [ab lob] or
> > descendant, or across a file boundary. This is probably the most Pd-like,
> > and what I'd likely go with by default, as it fits best with the pd/ab
> > object analogy.
>
> So I want to clarify some misconceptions.
>
> - [ab <name>] is local to our root canvas, including all child [ab] objects.
>
> root canvas-- canvas returned by canvas_getrootfor. E.g., either a
> toplevel patch or the main canvas of a **file** abstraction
>
> What has ruled development since the beginning is the idea of *private* patch abstractions, in other words, abstractions whose definition is stored and handled locally within a patch file. The idea is keeping everything inside a closed box (the .pd file), in this way we avoid a lot of problems.
> For this reason, crossing file boundaries is not suitable, as it can lead to missing definition issues, as is currently the case with templates.
>
> - [ab $0-<name>] follows the same rules as [ab <name>], but it will only be instantiated by canvases that know our $0. Therefore, it is highly unlikely that child [ab] objects will be able to instantiate it.
>
> I previously wrote:
> > * This 'local scope' won't be, in fact, a real local scope but the
> > string '$0-name' is much harder to reproduce by the user because he must
> > know the '$0' ID of the patch where the local abstraction has been created.
>
> > If a real local scope is wanted then we will have to deal with
> > conditional behaviour that may make the feature even harder to implement.
>
> As I state, it is not, in fact, a real local scope.
>
>
> -----
>
> Regarding 3:
>
> > 3. We currently have no way to declare "local to root including child
> > [ab] objects"
>
> If I'm not missing anything, this is how it currently works, as I explained a bit above.
>
> To conclude:
>
> We can create (2) and (3) [ab] objects but not (1).

Ah, I'm mixing up my definitions for "root" here.

What I mean is that $0 doesn't get you normal lexical scoping rules:

Suppose I have [ab three] inside [ab two] inside [ab one].

If I define [ab $0-counter] inside [ab two], it's true that it is
unlikely to nameclash with anything in [ab one].

However, [ab three] is not able to access it, either.

So it's not possible to get "local to the highest canvas it was
defined in, plus all child [ab] objects on that canvas."

-Jonathan

>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev