Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote: how can someone assume so? > no, that is so not true. i didn't even know, that zexy comes with their own version of [pack] and [unpack] until some weeks ago. and why the hell to they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals,
that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla.
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.
Huh? The only "incompatibility" is the new *feature* of alias names for overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature* implemented by popular demand. Loading libraries and the overwriting itself hasn't changed at all AFAIK. If you don't use the alias names, you don't have any problems.
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.
but maybe I'm wrong. IOhannes?
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.
The overriding with lib-libraries works as before,
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.
I agree with you that external libraries generally shouldn't overwrite builtins. When using Cyclone for Max-importing it makes sense, though.
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...
But IMO the aliasing is less insane than not being able to use the builtins at all, as is the case if you load object-overwriting-libraries like zexy or cyclone in any Pd version before 0.42, including pd-extended.
aliasing is not bad. what is bad is the way the aliases are generated
Note that here I use libraries in the "-lib"-loading many-externals-in-one-file sense here, not in the sense where everything (libs, singles, abstractions, "libdirs") is called a library and setting a path is called "loading a library".
yes, i agree we should not call adding a path "loading a library". "expanding the namespace" might be better.
mhadft IOhannes