Ed Kelly wrote:
Otherwise there are nameclashes that can seriously screw up a collection of abstractions.
(Key paragraph wrapped in ****** below)
One way of fixing this once and for all would be to have a separate [objectmaker] for each canvas (including abstractions, but not subpatches, ie, those canvases that have a t_canvasenvironment attached to them - at least that is how I understand that part of Pd's code).
HCS's [import], as far as I understand the code, just adds canvas-local paths, but the single global [objectmaker] lets externals clash unless you use qualified names everywhere you use objects. A canvas-local [objectmaker] really would provide the necessary separation to allow abstractions from different worlds not to collide in a horribly crunch.
I have a vague sketch of an implementation like this already, but it's quite brutal to the core of Pd so I doubt the changes would be accepted by anyone without me cleaning it up a lot and providing a clean .diff to a current development version of Pd... Currently the *only* object that can be instantiated in an empty canvas in my implementation is [import]. [import foo] will load the foo library's manifest into a new [objectmaker] and store it in a map (so importing libraries multiple times doesn't do more work), and objects defined by the library are only setup() at most once too (on demand at first creation).
It's a pain in the arse to use at the moment though, as it's not instinctive to type [import vanilla] as the first thing in a patch, and abstraction support is broken completely at the moment. The manifest is a bit of a wart, too - it explicitly lists all file names and the classes that are provided by them (in place of hardcoded hexmangling etc, but this also allows for multi-object libraries and eventually a "[fu] not found, you might try [import karate] or [import sumo]" useful message).
BUT: the "killer application" of this canvas-local [objectmaker] mechanism is already apparent: you can have one patch massive.pd that loads an external like [import foo-library],[snazzy-filter] and another patch (or abstraction) bonanza.pd in the same Pd instance can do [import bar-library],[snazzy-filter] and each will get only the [snazzy-filter] that it desires.
I'm still undecided about what would be best to do if kerplunk.pd does [import foo-library bar-library],[snazzy-filter] - probably some qualified naming could work for that, either at point of import like [import foo-library/snazzy-filter bar-library] in which case the most-qualified version takes precedence (like CSS) or at point of use like [import foo-library bar-library],[foo-library/snazzy-filter] - the first would make patches shorter but the second would still be necessary in some cases too. Verbose and useful messages about what is going on would be the first priority, in any case.