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

[Alexandre Torres Porres]

2016-04-05 20:37 GMT-03:00 cyrille henry <ch at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160406/e4d4768e/attachment.html>