[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

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.

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,

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