[L2Ork-dev] Patch private abstractions

[Matt Barber]

re: 1002-counter

Is there 1002 hard-coded into the file? If there are ten instances of ab
two are there ten separate definitions for this counter? Do the individual
instances necessarily retain their $0 IDs across reload?

Matt

On Mon, Aug 17, 2020, 5:04 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> 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
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200817/ddc1ee6e/attachment-0001.html>