[L2Ork-dev] Patch private abstractions

[Jonathan Wilkes]

On Fri, Jul 31, 2020 at 7:03 AM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
>
> > I wonder if it even needs to have the ability to be opened. If you get rid of
> > that requirement then you get rid of a lot of the special cases like not drawing
> > xlets and such.
>
> As far as I know, the only requirement for objects to be able to be open is just having the "menu-open" method defined. Adding a custom open method shouldn't be a big problem.
>
> > In other words the object could just mean, "this is an abstraction
> > name (or list of names) to be saved with this patch file." Then the user
> > creates a new object by that name,
> > initially getting an empty patch window but filling it up with their
> > desired content.
>
> It's a good idea. Users will be able to define all the abstraction names at once, instead of
> creating an [ab define <name>] object for each abstraction. In this way, not having the ability to be open makes sense.
>
> > What happens if instance [ab <name>] is edited and saved?
>
> Yes, I forgot to mention what is supposed to happen. All instances of that kind are updated as well.
>
> > 1. As above, I think allowing a click to open a subpatch for [ab define]
> > is superfluous. Users will tend to immediately do [ab <name>] and
> > create/edit/save in the instance as they do with abstractions.
>
> Yes, I agree.
> Regarding this approach of defining the abstraction names using [ab define <name1> ... <namen>] and editing them through their instances, I wonder if it's even necessary to declare the list of abstraction names separately.
> Couldn't it work with just the [ab <name>] instances?
> - If[ab abs1] is typed into an object and the abstraction definition for 'abs1' doesn't exist, then it is created. Otherwise, if the definitions already exists, [ab abs1] is going to be an abstraction of that kind.

The one reason I can think to have explicit name definitions is for scoping.

Compare:

function foo() {
    y = 14;
    z = function() {
        y = 12;
    };
}

function foo() {
    var y = 14;
    var z = function() {
        y = 12;
    };
}

In the first example, there must be an implicit scoping rule and the
user is stuck with whatever it is.

In the second example, the existence or absence of "var" gives the
user control on the scope of the 2nd "y".

For [ab] I can think of three approaches:

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.

2. [ab define] for defining scope. In this design, [ab] names can
cross file-abstraction boundaries. So the presence of [ab define] says
"this is the furthest level up that an [ab] by this name will share
the same contents as the others." Similar to
how "var" works in javascript, and how [preset_hub] works in Purr Data.

3. [ab define] with a numeric argument for climbing out of a
file-based abstraction to the parent. I do this with [canvasinfo]
so that the user can build useful abstractions with it. E.g.,
[canvasinfo 1] affects the canvas that is the parent of its current
canvas. That way users can build abstractions with it-- otherwise the
abstraction could only query its own state. So
[ab define 1] would mean that the names affect everything from the
canvas that contains our current canvas, down.

Those are in increasing order of complexity. It's probably best to
start with your design and see whether that fits most use
cases.

> - The abstraction definitions must be hoisted as well so they can be found by all objects within the scope, when we are loading the file.
> - When the last [ab abs1] object is deleted, the abstraction definition for abs1 is deleted as well.
> - The abstractions can be edited/opened from all of their instances.
>
> > 2. Now I'm wondering-- let's say you have [ab define foo] and it opens
> > a subpatch.
> > What if that subpatch were just a place to put data to be shared by
> > all the abstractions?
>
> > For example, there could be an [ab send] and [ab receive] so that
> > abstractions could
> > register themselves with that shared subpatch which keeps track of their number.
>
> This has a lot of potential.
> It's clearly incompatible with the approach which abstraction names can be defined with [ab define <name1> ... <namen>]. On the other hand, is compatible with the first approach I did, in which abstractions are defined individually using [ab define <name>]. It is also compatible with the the second approach (this little one above), in which we don't really need to define the abstraction name. In this case an optional object [ab data <name>] could be created and filled with data that would be shared by all the <name> abstractions.

While it's not a priority, it's something to keep in mind. Matt may be
able to shed some light on whether something like
that could be generally useful or just esoteric.

Best,
Jonathan

>
>
>
> Guillem,
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev