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

[cyrille henry]

Le 06/04/2016 06:09, Alexandre Torres Porres a écrit :

>
>     So, i don't see any problem overwriting vanilla objects, as long as object developers don't do anything stupid.
>
>
> well, I pointed some existing issues that lies outside what you pictured... and there is also other issues besides internals.

I see many example of the same issues, but not many issues.

overwriting internals did not change anything in library clash-name problem.

but yes, there is a problem in cyclone.
using cyclone as a libdir solve the name conflict problem, but not "weird" name object.
using cyclone as a regular lib solve the weird name, but not conflict.


> well, it really makes sense to me not to bother to think of a vanilla abstraction to substitute 2 existing externals that I already have...
i think it take less time to write a 2 object abstraction than sending this kind of mails.

>
> And I can also remember several other external objects with the same name that aren't compatible - such as "uzi" as an alias of kalashnikov or uzi from cyclone...
they all obsolete since vanilla introduce [until], 10 years ago ;-)


>
> it just makes a lot of sense to me tha Pd allows the user to have some control over what objects and externals to call.
yes, obviously.
it's the case when using libdir format, but not when using regular lib. this is bad.


>
> Way things are now, we have NO control whatsoever and this is bad.
they have control :
load a lib if you want to use it. did not load it if you did not want to.


You cannot guarantee that your patches will work as they should anywhere.
the ONLY solution to work everywhere is not to use external.
if you do, the most safe solution is to load pd with -noprefs and load preference per patch.
overwriting internals did not increase this problem, no solve it.


It would be good to attack this problem by actually allowing control to the user, instead of being happy with laboring workarounds that don't really solve anything and might even create more hassle...
>
I understand that you are upset because it break cyclone, but except that, it's a nice feature (that should only be use wisely)

> I can think of many options to allow control to the user. Not allowing vanilla objects to be overwritten is one. Allowing a user to choose an object from a specific library os another. Both would solve this... and seems like the best solution to me. On the other hand, I cannot think, yet, of any good reason to leave things the way they are.
>
usually, it take me 10 years to understand why miller made the right choice ;-)

cheers
c


> cheers