[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

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).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200817/a997bf0a/attachment.html>