Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The Lua-style "environment" in Pd is basically just the global path
and the global helppath.
Maybe. But Lua also does have a path variable ("package.path") which is very similar to Pd's -path as it's used to specify where to search for modules.
package.path however is practically never modified and stays the way it is through the lifetime of a program. The whole namespace/enviroment manipulation happens elsewhere. By separating searchpath and namespace manipulation Lua gains a lot more flexibility than Pd has.
To illustrate this a bit more: In Lua, the function "require" loads modules from the searchpath and then can manipulate the namespace (Actually "require" doesn't do any namespace manipulation itself, instead that's in the responsibility of the module loaded.) "require" is the *only* function that actually accesses the package.path variable. package.path is generally unused everywhere else.
In Pd, the global path is used to directly manipulate the namespace. This is much more limited, full of side-effects and for example is the only reason that multi-class libraries had to be deprecated in pd-extended - which still ships some of these: Gem and PDP.
I'm not yet sure what model a better namespace manipulator could follow, but with the loader infrastructure, we maybe have all the hooks already in place to make a better namespace modifier that doesn't use the path in the old way. For example such a loader could be made to load Gem with an object prefix (whatever use this may have)
Ciao
Frank Barknecht