Hi list, Let's say I make a patch that uses the zexy and hcs libraries. I want my patch to be portable to Pd-extended, Pd-l2ork, and whatever hand-rolled Pd-vanilla+zexy+hcs installations are sitting out there on users machines.
If that is my goal, then I am going to use libdir/objectname syntax for all my zexy and hcs objects in my patch. I am going to do this because if a user ever reports that there is a nameclash, it is very likely to be due to a bug somewhere, and that bug is very likely to be fixable.
In fact, I will go so far as to say there is no other way to make a portable patch that uses externals on the versions of Pd I described above...
both [import] and [declare] will happen _after_ the the default libs of Pd-extended/L2ork are loaded, so I can't use unprefixed object names with impunity (same with .pdrc). And even if it does work, it's not future-proof, as someone may add an object that aliases one I'm using in my patch.
command lines flags don't ship with my patch, and they get parsed _after_ the user or default prefs so again, I'm just hoping to get lucky.
even with Pd-extended's current "load-nothing" dogma, all possible object names are stored globally (in what looks like both prefixed and unprefixed forms, like "foo/bar" and "bar"). So if my patch is an abstraction and I don't use libdir/objectname syntax for the object names within it, all I can do is hope the user hasn't already loaded something that aliases one of my objects. (And again, not future-proof)
I see only two possibilities, then: either the community changes the core functionality so that there is a local object-name table for each canvas-environment*, or libdir/objectname should be the canonical way to make portable patches. Since libdir/objectname exists and "canvas-environment-local namespaces" don't, I suggest libdir/objectname as the only workable approach.
However, I'm only about 3/4 of the way through reading and comprehending the library-loading code in Pd. So if anyone has thoughts or suggestions I'm all ears.
-Jonathan