[L2Ork-dev] Patch private abstractions
guillembartrina at gmail.com
Fri Jul 31 06:57:50 EDT 2020
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the L2Ork-dev