[PD] Name conflicts "class overwritten; old one renamed 'x_aliased'

cyrille henry ch at chnry.net
Wed Apr 6 01:37:23 CEST 2016


hello,

overwriting a vanilla object is relatively new feature. Newer than last pd-extended, that's why it did not make it to extended.
pd-l2ork is more recent, so i guess it use all latest vanilla feature.
I think the aim is to be able to create object that are more optimized than native one. Or that add functionalities.
Of course, one can use this feature to completely break pd.

"rm -rf /" is a command that will completely break your computer, but it will not be remove from your OS, because no one sane would try it.
it's the same for pd : no one sane would write a [+] object that did not add number.
but it's possible to develop a [+] object that add number and string.

there is no problem overwriting a vanilla object as long as you keep compatibilities.
if you don't keep vanilla compatibilities, chances are that no one will use your externals, since it will cause more problem than anything else.
So, i don't see any problem overwriting vanilla objects, as long as object developers don't do anything stupid.


anyhow, it make sens to be able to load zexy/<~ or nettles/<~ even if zexy and nettles are loaded as a lib. but [<~] is not vanilla, so this is an other discussion than vanilla object being overwritten.


and for this specific object, what make more sense to me is to use a small abstraction made around tabread~ and a 2 points table.
100% vanilla.
0% trouble.


cheers
cyrille



Le 06/04/2016 00:51, Alexandre Torres Porres a écrit :
> howdy, as a remaining extended 0.42-5 user, I'm just now realizing how vanilla works when loading externals with the same name as a vanilla object or some other preloaded library - I have to say it was a surprise to see that it's different that how extended works, and that it doesn't seem like a good idea...
>
> Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone (individual binaries but also has the nettles library) on vanilla 0.46-7 - both external libraries have abs~ (which is also a vanilla object) or an object like [>~] (part of nettles in cyclone). Both zexy and nettles are loaded via startup.
>
> So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's and renamed to abs~_aliased, but if I call cyclone's abs~ specifying its folder as [cyclone/abs~], it overwrites zexy's abs~ and it is never possible to call zexy's abs~ ever again...
>
> Ok, in the case of abs~ I think it should be removed from both cyclone and zexy, because it's not only that they share the same name between each other and a vanilla object, but they all do the same thing as the internal object... so it's completely redundanct - but this is another issue. One way or another, it helps illustrating my point.
>
> So, moving on to the case of [>~], we see from previous discussions that they need to be loaded as libraries for sanity's sake. But then I can never specify which [>~] I want - if both are via startup or declare, I can never be sure or control which one I'm specifying as either >~ or >~_aliased...
>
> The point is: perhaps there could be a better way to force vanilla to load an internal object?
>
> Or if not a vanilla object, perhaps that could be a way to specify and object inside one external library or another?
>
> The way things are, it's all just really out of control and I can think of many scenarios where patches need to be edited when loaded because of what's going on in that particular machine, such as what patch had been opened before, etc... I know this probably has been discussed for ages and many people had already thought about it... I also know I have NO clue on the technical details and what has already been done, but I would like to ask and suggest things.
>
> What would make sense to me is that vanilla objects would always prevail and be called with priority. This is how things were in Extended (and now pd-l2ork I guess) - externals with the same name as a vanilla objects could only be called only if explicitly specified.
>
> In the case of cyclone's [line~] it's easy to specify if you wan cyclone's version or not by specifying the folder [cyclone/line~]
>
> But the problem is when you're using a library, because you seemingly can't specify a given loaded external library when instantiating an object... such as [zexy/<~] or [nettles/<~] - and yes, they are different, by the way, before anyones asks ;)
>
> So, in short, all could be sorted and taken care if:
>
> 1- vanilla objects are never overwritten
> 2- external objects can be specified by a path even if they are loaded as a library with declare or via the startup (ex: zexy/<~ or nettles/<~)
>
> cheers
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>



More information about the Pd-list mailing list