Frank Barknecht wrote:

this i don't understand; it is an incompatibility between prior and post 0.42, no matter whether you are using pd-vanilla or pd-ext. just because pd-ext is still far from 0.42, doesn't mean that it will take counter-measures when the time is ripe.

imo, the entire "alias" thing does not deserve it's name. who will ever want to have [pow~_alias] in their patches?

now what happens if we have 2 (multi-object) libraries loaded, both of them containing [pow~]. do we get [pow~_alias_alias] or will the internal just vanish from the users scope? if so, why is there an arbitrary boundary at 2?

this all brings back the original idea of implicetely adding the libraries name somehow for aliases. e.g. [pow~] in pd, lib1, and lib2 (in this order) 1. Pd's [pow~] 2. lib1 gets loaded; the original [pow~] becomes [pd/pow~]; the lib1's one is now known as [pow~] 3. lib1 get's loaded; Pd's [pd/pow~] stays untouched; lib1's one becomes [lib1/pow~]; the new one is know as [pow~]

darn, this is all the thing i have written 6 (or so) years ago. i remember there have been good reasons not to do it like this.

nevertheless, the idea is kind of re-occurant to me; and i firmly believe it is a better solution than to add an "_alias" suffix.

overriding with single object externals never worked, because Pd does not see a reason to even try and open a library file which could then overwrite the internal.

no it does not. Pd never (that is: prior to 0.42) provided a way to overwrite existing classes. this holds true for multi-object libraries. cyclone did some very special tricks to override existing objects.

btw, it tried to do so in a quite sensible way: if the new cyclone-object failed to create (e.g. because of wron arguments to the object), it would fall-back to the original object.

actually i don't see a big problem. it would be the external's responsibility to maintain full compatibility. if it is not compatible (like zexy's [pack] right now), then this is just a bug in the external. the problem with zexy's [pack] overriding the internal was just because i was caught on the back foot, believing that i was save for now until the incompatibililties were fixed...

aliasing is not bad. what is bad is the way the aliases are generated

yes, i agree we should not call adding a path "loading a library". "expanding the namespace" might be better.

mhadft IOhannes