[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

Hi,

In the last meeting we (more or less) conclude that the most ergonomic 
approach is the one that simply uses [ab <name>], with implicit creation 
and deletion for the shared abstraction definition and an implicit flat 
scope (instantiable by the whole subpatch/abstractions tree, even if 
first definition was in an other branch or a deeper level or inside an 
abstraction).

Local scope for these kind of abstractions will be achieved using [ab 
$0-<name>].

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


The flat scope mentioned above scares me a little because it might be 
the source of a lot of problems. To start with, a clean and strong 
storing and lookup system for the shared abstraction definitions must be 
designed and tested.

Possible problems:

- We have to prevent instantiating abstractions within themselves (or 
one of their descendants).

- Possible name clash with other private abstractions when instantiating 
file-based abstractions.

- Where should the abstraction definitions be stored within the pd file, 
to prevent code repetition like the subpatches? Maybe hoisted inside the 
root patch definition, as is currently implemented.

----------------------------

The first approach I showed you yesterday was based on Jonathan's approach:

> 1. Implicit as you describe above. Rule: the names go from the root>
> down to the subpatches without
> affecting file-based abstractions in the root or the subpatches. If
> the [ab name] exists inside a file-based abstraction, it doesn't
> affect the parent on which the abstraction was created.

If I understood correctly, the goal now is the same but the scope now 
crosses file boundaries.

Best,





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