[PD] naming objects

[Claude Heiland-Allen]

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.


Claude
-- 
http://claudiusmaximus.goto10.org