On Wed, 2010-07-14 at 08:31 +0200, Frank Barknecht wrote:

Your interpretation does not quite reflect, how [declare] currently behaves:

* [declare]ing a path in top level patchA.pd does not affect top level patchB.pd. In that respect, [declare] _is_ canvas local.

* [declare]ing a path in abstraction [abs] which is instantiated in patchA.pd does not affect patchA.pd. Also in this respect it is canvas local.

* A [declare] with a flag, that is supposed to be relative to the patch ('-lib' and '-path') expands always only relative to the path of the most top level patch (see your example). This actually renders those flags unusable within abstractions.

* [declare -stdlib] and [declare -stdpath] still can be used within abstractions, since those flags are relative to the Pd path and thus independent from the most top level patch.

* [declare -lib] and [declare -stdlib] cannot load a class library or single classes canvas local. But this is probably more related to the classloader of Pd than specific to [declare] (and is the same with [import]).

* [declare] still has bugs. When saving a patch after having instantiated an abstraction containing a [declare], the patch is polluted with a hidden [declare]. This does not mean, that [declare] is not canvas local.

This is also not true. The combo libdir and [import] behaves very similar to [declare -stdpath] in that it is canvas local in the same respects as described above and also in that it expands pathes relative to Pd. A difference is, that it requires a mylib-meta.pd patch. If you want, [declare] is an extended [import] with bugs under certain circumstances.

After all, I don't see why one should restrict themselves in [declare] usages as you propose it, OTOH it's certainly safe.

Roman