<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi, sorry for the late reply; I don't get much email time on weekends.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">One thing I feel very strongly about is keeping syntax and semantics relatively consistent across the various objects. So [ab define] should work as close as possible to [array define] and [text define]; otherwise something besides "define" should be used in order not to cause confusion.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I actually agree that [ab define] may turn out to be redundant and that [ab <name>] could work on its own, using [ab <name>] for every instance. I like it better than any other options. It would have the advantage of being similar to [pd <name>], and it would also obviate any issue with loading objects. The tricky thing may be the patch loading process. It may be worth sorting instances so that the contents are stored advantageously within the patch. Its use with [clone] may take a hit as well. If this is the option we go with, I think saving in the [ab <name>] canvas could save the whole patch as it does with [pd <name>], but it should also work similarly to regular abstractions, so some windows may need to be closed etc.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Just thought of something to flag: let's talk about what should happen with [initbang].</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Scope is something I need to think about more. The most pd-like thing would be flat scope and [ab] objects sharing names between main patch and file abstractions throwing a "multiply defined" error as with [catch~], say. Then local scope would be [ab $0-name] as it always is with everything else. I kind of hate this but it's in keeping with pd design. If we go with [ab define <name>] and [<name>] instances, scope is a lot more complicated but should probably follow similar scope to file abstractions, which I always forget but imagine is strictly local relative to path (that is, abstraction names can't propagate down to abstraction instances unless they share a path, in which case it's not really propagation but just flat scope again).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks for thinking through this so carefully.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 31, 2020 at 2:55 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 31, 2020 at 7:03 AM Guillem Bartrina<br>
<<a href="mailto:guillembartrina@gmail.com" target="_blank">guillembartrina@gmail.com</a>> wrote:<br>
><br>
> > I wonder if it even needs to have the ability to be opened. If you get rid of<br>
> > that requirement then you get rid of a lot of the special cases like not drawing<br>
> > xlets and such.<br>
><br>
> 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.<br>
><br>
> > In other words the object could just mean, "this is an abstraction<br>
> > name (or list of names) to be saved with this patch file." Then the user<br>
> > creates a new object by that name,<br>
> > initially getting an empty patch window but filling it up with their<br>
> > desired content.<br>
><br>
> It's a good idea. Users will be able to define all the abstraction names at once, instead of<br>
> creating an [ab define <name>] object for each abstraction. In this way, not having the ability to be open makes sense.<br>
><br>
> > What happens if instance [ab <name>] is edited and saved?<br>
><br>
> Yes, I forgot to mention what is supposed to happen. All instances of that kind are updated as well.<br>
><br>
> > 1. As above, I think allowing a click to open a subpatch for [ab define]<br>
> > is superfluous. Users will tend to immediately do [ab <name>] and<br>
> > create/edit/save in the instance as they do with abstractions.<br>
><br>
> Yes, I agree.<br>
> 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.<br>
> Couldn't it work with just the [ab <name>] instances?<br>
> - 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.<br>
<br>
The one reason I can think to have explicit name definitions is for scoping.<br>
<br>
Compare:<br>
<br>
function foo() {<br>
y = 14;<br>
z = function() {<br>
y = 12;<br>
};<br>
}<br>
<br>
function foo() {<br>
var y = 14;<br>
var z = function() {<br>
y = 12;<br>
};<br>
}<br>
<br>
In the first example, there must be an implicit scoping rule and the<br>
user is stuck with whatever it is.<br>
<br>
In the second example, the existence or absence of "var" gives the<br>
user control on the scope of the 2nd "y".<br>
<br>
For [ab] I can think of three approaches:<br>
<br>
1. Implicit as you describe above. Rule: the names go from the root<br>
down to the subpatches without<br>
affecting file-based abstractions in the root or the subpatches. If<br>
the [ab name] exists inside a file-based abstraction, it doesn't<br>
affect the parent on which the abstraction was created.<br>
<br>
2. [ab define] for defining scope. In this design, [ab] names can<br>
cross file-abstraction boundaries. So the presence of [ab define] says<br>
"this is the furthest level up that an [ab] by this name will share<br>
the same contents as the others." Similar to<br>
how "var" works in javascript, and how [preset_hub] works in Purr Data.<br>
<br>
3. [ab define] with a numeric argument for climbing out of a<br>
file-based abstraction to the parent. I do this with [canvasinfo]<br>
so that the user can build useful abstractions with it. E.g.,<br>
[canvasinfo 1] affects the canvas that is the parent of its current<br>
canvas. That way users can build abstractions with it-- otherwise the<br>
abstraction could only query its own state. So<br>
[ab define 1] would mean that the names affect everything from the<br>
canvas that contains our current canvas, down.<br>
<br>
Those are in increasing order of complexity. It's probably best to<br>
start with your design and see whether that fits most use<br>
cases.<br>
<br>
> - 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.<br>
> - When the last [ab abs1] object is deleted, the abstraction definition for abs1 is deleted as well.<br>
> - The abstractions can be edited/opened from all of their instances.<br>
><br>
> > 2. Now I'm wondering-- let's say you have [ab define foo] and it opens<br>
> > a subpatch.<br>
> > What if that subpatch were just a place to put data to be shared by<br>
> > all the abstractions?<br>
><br>
> > For example, there could be an [ab send] and [ab receive] so that<br>
> > abstractions could<br>
> > register themselves with that shared subpatch which keeps track of their number.<br>
><br>
> This has a lot of potential.<br>
> 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.<br>
<br>
While it's not a priority, it's something to keep in mind. Matt may be<br>
able to shed some light on whether something like<br>
that could be generally useful or just esoteric.<br>
<br>
Best,<br>
Jonathan<br>
<br>
><br>
><br>
><br>
> Guillem,<br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>