<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>The following approach, suggested by Matt, is the source of the
current implementation:<br>
</p>
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">> 1. [ab <name>] abstractions are treated as every bit as local as [pd
> <name>] subpatches, except for each instance has a private $0. [ab <name>]
> definitions do not cross file boundaries, either up to parent or down to
> file abstractions, but the can cross [ab <name>] boundaries, so that [ab
> lob] first defined as root->[pd foo]->[ab bar]->[ab lob] can be
> instantiated anywhere else in root except in another [ab lob] or
> descendant, or across a file boundary. This is probably the most Pd-like,
> and what I'd likely go with by default, as it fits best with the pd/ab
> object analogy.
So I want to clarify some misconceptions.
- [ab <name>] is local to our root canvas, including all child [ab] objects.
root canvas-- canvas returned by canvas_getrootfor. E.g., either a
toplevel patch or the main canvas of a **file** abstraction
What has ruled development since the beginning is the idea of *private* patch abstractions, in other words, abstractions whose definition is stored and handled locally within a patch file. The idea is keeping everything inside a closed box (the .pd file), in this way we avoid a lot of problems.
For this reason, crossing file boundaries is not suitable, as it can lead to missing definition issues, as is currently the case with templates.
- [ab $0-<name>] follows the same rules as [ab <name>], but it will only be instantiated by canvases that know our $0. Therefore, it is highly unlikely that child [ab] objects will be able to instantiate it.
I previously wrote:
> * This 'local scope' won't be, in fact, a real local scope but the
> string '$0-name' is much harder to reproduce by the user because he must
> know the '$0' ID of the patch where the local abstraction has been created.
> If a real local scope is wanted then we will have to deal with
> conditional behaviour that may make the feature even harder to implement.
As I state, it is not, in fact, a real local scope.
-----
Regarding 3:
> 3. We currently have no way to declare "local to root including child
> [ab] objects"
If I'm not missing anything, this is how it currently works, as I explained a bit above.
To conclude:
We can create (2) and (3) [ab] objects but not (1).
</pre>
</body>
</html>