[PD] name collisions, namespaces ..

IOhannes zmoelnig zmoelnig at iem.kug.ac.at
Wed Aug 28 14:25:35 CEST 2002


Juha Vehviläinen wrote:
> Ouch.

hi !

>>Hi Juha,
>>one other potential problem is that the [zexy] object must then be loaded
>>before all the objects you want to reference from the zexy library.
>>Otherwise they wont't be found.
>>I'm not sure if one can always be in control of this.

>>>If a patch with [maxlib] on it would give preference to objects
>>>on maxlib, that would be the namespace thing done in minimal

well, i always think it is good style to define dependencies (on 
libraries) in the patch itself. in fact, most of my patches look like 
this (maybe some (a lot?) do not)
some years ago (??, really ?), i've proposed an additional "object"-like 
GUI-representation for loading libraries / showing dependencies (kind of 
"import"-thing). it was then rejected by most.

i would think, that placing a (say) [zexy] (or {import zexy}) in an 
abstraction, should set a priority to use zexy-externals, whenever 
nameclashes appear, in this very patch (subpatch?).

example:
starting pd with "pd -lib Gem -lib zexy".
1) a patch containing [abs~] would naturally use Gem's [abs~]
2) a patch containing {import zexy} would use zexy's [abs~] instead.
3) a patch containing {import abslib zexy} would load the abslib-library 
(and offer its additional features like [absinth] from now on, just like 
ordinary library loading), use abslib's [abs~] and zexy's [reson~]

i would not dare/like to implement this feature and change pd's library 
loading mechanism.
as a by-product, it is very likely that the (discussed) 
namespacing-mechanism ([zexy::abs~] vs. [Gem::abs~]) would have to be 
implemented anyway.
i think that this would be simpler and be able to handle all problems 
apropriately.

mfg.cds.asdr
IOhannes





More information about the Pd-list mailing list