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".
- a patch containing [abs~] would naturally use Gem's [abs~]
- a patch containing {import zexy} would use zexy's [abs~] instead.
- 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