[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

> 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 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.



Guillem,

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