<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I see three basic approaches to scope:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. [ab <name>] abstractions are treated as strictly private as file abstractions, so definitions inside cannot pass out to parent or down to other [ab <name>] descendents]. In other words you treat [ab <name>] as though it were a file boundary. This is also pretty Pd-like, and I would likely go with it if we were going with a model where you could [ab define jinx] and then use [jinx] on its own without needing to call the [ab] object.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3. [ab <name>] abstractions are treated as a kind of hybrid. [ab lob] defined as [ab bar]->[ab lob] can be used in any instance of [ab bar] and descendents (including [ab <name>] descendents) but not in parent or root. If root already has an [ab lob] defined, it will be replaced by the new definition in [ab bar] instances. This is normal programming local scope, is elegant, and is therefore least Pd-like.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Other considerations:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">You could send messages to ab-<name> and access every instance.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Name clash. Should the [ab] names be their own separate thing, so that [ab counter] and a file abstraction called by [counter] are different? Is that even possible? Likewise should [ab float] be possible without conflicting with builtin, or [ab z~] without conflicting with an external? This could preclude use with [clone], except it could still be done with [clone ab-counter] to distinguish from the file-defined [clone counter].</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I don't have strong opinions about that yet.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">What happens if one deletes all instances of [ab foo]? I think the patch should somehow remember the definition so that it can be instantiated again. That probably means it should be hoisted to root and not associated with any instances at all.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Will [savestate] work? It doesn't work with [clone]. What does [initbang] do if you are trying to use it to dynamically patch inside instances (I think it should behave about like it does in file abstractions, but there could be problems I haven't thought of yet).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 5, 2020 at 7:08 AM Guillem Bartrina <<a href="mailto:guillembartrina@gmail.com">guillembartrina@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>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). </p></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Local scope for these kind of abstractions will be achieved using
[ab $0-<name>]. <br>
</p>
<p>* 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.</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.</p>
<p>Possible problems:</p>
<p>- We have to prevent instantiating abstractions within themselves
(or one of their descendants).<br>
</p>
<p>- Possible name clash with other private abstractions when
instantiating file-based abstractions.</p>
<p>- 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.<br>
</p>
<p>----------------------------<br>
</p>
<p>The first approach I showed you yesterday was based on Jonathan's
approach:</p>
<pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">> 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.
</pre>
<p>If I understood correctly, the goal now is the same but the scope
now crosses file boundaries.</p>
<p>Best,<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div>