Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
I think, it's not yet "pretty clear" at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic.
The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.)
Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either
a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here]
It could also be realised with messages sent to "pd-subname", but that's probably not a good idea because of execution order problems. Or is it?
Ciao