2016-04-05 20:37 GMT-03:00 cyrille henry <ch@chnry.net>:

pd-l2ork is more recent, so i guess it use all latest vanilla feature.

not really, seems pd-l2ork hasn't been kept up to date to any specific vanilla versio, like extended used to, so it's definitely a forkk per se. And for what I tried, pd-l2ork behaves like extended 0.42-5, what I'm using as a basis for comparison. I also tried vanilla 0.42-5 and saw that it already have the overwriting feature, so I assumed is something they didn't want in extended (0.43 still didn't have the overwritting, huh?).

I think the aim is to be able to create object that are more optimized than native one. Or that add functionalities.

Seems not healthy in any way. If you want to make a better pd, well, you can chose different names for externals, or really just fork it.

In general, I don't see any good reason to have externals with the same name as vanilla internals, other than max/msp clones like good old cyclone - but the way to deal with in extended worked fine, if you want line~ that is compatible to max, use cyclone/line~

Of course, one can use this feature to completely break pd.

yep

it's possible to develop a [+] object that add number and string.

also possible to give it another name, or even to call [+] in a way that is not overwritting an internal.

there is no problem overwriting a vanilla object as long as you keep compatibilities.

well, for one, cyclone/line~ is not compatible.

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.

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.

another discussion, but quite parallel and that arise from the same matter.

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.

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...

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...

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.

Way things are now, we have NO control whatsoever and this is bad. You cannot guarantee that your patches will work as they should anywhere. 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 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.

cheers