[L2Ork-dev] Patch private abstractions

Jonathan Wilkes jon.w.wilkes at gmail.com
Mon Aug 17 17:03:59 EDT 2020


On Mon, Aug 17, 2020 at 2:56 PM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
>
> Hi,
>
> > 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.
>
> Regarding the current implementation, the definition for "$0-counter", created initially inside [ab two], is stored in the root canvas (root canvas-- canvas returned by canvas_getrootfor. E.g., either a toplevel patch or the main canvas of a **file** abstraction), so its reachable from both [ab one] and [ab three].
>
> [root]
> $0 = 1000
> *definition for: 'three', 'two', 'one' and '1002-counter' are here*
> ----------------------------------------------------------
> |                                                        |
> [ab three]                                               [fileabs]
> $0 = 1001                                                $0 = 1005
> -                                                        *definition for 'four' is here*
> |                                                        -
> [ab two]                                                 |
> $0 = 1002                                                [ab four]
> -----------------------                                  $0 = 1006
> |                     |
> [ab one]              [ab $0-counter]
> $0 = 1003             $0 = 1004
>
>
> All private abstraction definitions are stored on the root canvas and are accessible by all subpatches and all [ab] objects within the subtree, but not by *file* abstractions, which follow this same scheme but by themselves.
>
> In this way we achieve a flat scope for the whole file, keeping it all private to the file. Therefore, file abstractions don't have access to the definitions stored in the root canvas. (e.g. 'fileabs' abstraction does not see definitions for 'three', 'two', ...)
>
> -----
> > So it's not possible to get "local to the highest canvas it was
> > defined in, plus all child [ab] objects on that canvas."
>
> This was possible using the [ab define] approach, but not in the current implementation. Anyway, the "plus all child [ab] objects on that canvas" is tricky. Since the mentioned childs  are global [ab] objects, they can be instantiated anywhere within the subtree, and all of them with the same name share the definition. So, if we create an instance of a 'local' ab (e.g [ab $0-foo]) inside one of the mentioned ab childs (e.g [ab bar]), that 'local' ab ([ab $0-foo]) won't be local any more because any instance of that child ([ab bar]) anywhere in the subtree will have an instance of that 'local' ab ([ab $0-foo]) within it. This leads to a messy and chaotic scope system that will fry our brains.
>
> The only solution for this is return back to the [ab define] and therefore to a non-flat and nested scope.
>
> In addition, I don't see any use cases for this "local to the highest canvas it was defined in, plus all child [ab] objects on that canvas.", according  to the current definition of [ab] private abstraction objects with a flat scope.

So I think we all agree that it's quite a useful feature to have ab
definitions private to a **file** abstraction, as you wrote.
It's basic programming encapsulation.

But I think it's useful in another way-- it elegantly solves the
problem of namespacing conflicts in a way that no other current
feature in Pd does (aside from preset_hub/node).  I can have my [ab
counter] with two outlets inside my file-level abstraction,
and you can have your [ab counter] with one outlet in your file-level
abstraction, and they won't conflict. Even binary
externals can't do that because they are loaded into a global
namespace. So it's a very useful feature.

I can imagine users that want to have all their code in a single file,
but who also want to leverage the naming resolution
that file-level abstractions provide as described above. That's the
use case I'm thinking of.

So my question is this-- is there some way to decouple this elegant
naming solution from a reliance on file-level
abstractions? For example-- some kind of [ab scope] which just reports
itself as a file-level abstraction?

-Jonathan

>
> If it were only the first half, "local to the highest canvas it was defined in", I can think of several use cases. But it is, in fact, the [ab define] approach itself.
>
> Best,
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev


More information about the L2Ork-dev mailing list