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

[Alexandre Torres Porres]

2016-04-06 7:11 GMT-03:00 cyrille henry <ch at chnry.net>:

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

ok, an issue (name clashing) that has many examples it is then.


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

it did introduce the problem of name clashing between objects, being it
internal x external, or even between externals themselves - seems it just
made things worse.

The way things are, name clashing is up for chance, it's a gamble.


> but yes, there is a problem in cyclone.
> using cyclone as a libdir solve the name conflict problem


No it does not! Seems you're not grasping the issues I'm raising.

If I call [cyclone/line~] it will overwrite vanilla's [line~], and
[cyclone/line~] is not compatible to vanilla's - so name clashing and
incompatibility issues arise.

This is one thing between internal x external objects. If there was a way
to specify [vanilla/line~], them great! Problem solved. But you do not have
any control on how to call vanilla line~ once it's been overwritten.

using cyclone as a regular lib solve the weird name, but not conflict.


the case with regular libs, whatever they are, is that you can't specify
them when loading a particular object, at least I don't know how to do
that. So again you have name clashing when objects aere overwritten.


> 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 ;-)


No it's not obsolete as [uzi] has many features [until] doesn't have.
See... I get that Not using the externals is "a" solution, and one that I
actually thought of, but not the one I was after when raising this issue.
My motivations is finding a way to use externals and avoid name clashing,
so not using externals is not a valid solution for this issue.

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.


again, you seemed to not have realized that libdir also introduces issues -
so it is bad too, and it wasn't before!


> i think it take less time to write a 2 object abstraction than sending
> this kind of mails.


good for you, let me be the one to raise the issues then. I just hope you
are not saying I shouldn't bother raising issues I'm having to hopefully
getting them sorted out.


> You cannot guarantee that your patches will work as they should anywhere.
> the ONLY solution to work everywhere is not to use external.
>

So far it's true, that's actually part of my point, things needed to change
to allow us a way to guarantee it


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


Overwriting internals did increase problems and made new issues arise. At
least in Extended and Pd-l2ork I can specify if I want cylone/line~ or
vanilla line~ - it'd be nice too if Pd-l2ork offered a way to load a
particular external from a specific regular lib or another. With such both
features, we'd have a safe and guaranteed solution

I understand that you are upset because it break cyclone, but except that,
>> it's a nice feature (that should only be use wisely)
>>
>
yeah, but it's not really nice if it introduces issues and losses. and what
would you lose if you could specify wether you wanted an object from
vanilla or one library or another?

I get it that you do not have personal issues with the way things are, that
you are coping with it, but I'm not like that.


> usually, it take me 10 years to understand why miller made the right
> choice ;-)


Hey buddy, I'm open... but I need more than things like:

- Got a problem with externals? Do not use the externals then;
- Yeah, you do have a problem and I don't have a solution, but other than
that, the thing you are complaining about is nice.
- I, personally, don't mind the issue, and I think that some workarounds
are worth it
- You might not agree it is nice now, and I'm not really trying to prove
any point, but maybe if you give it 10 years you might change your mind

I still do not see any advantage in object overwritting, and I see how it
is causing name clashes.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160406/5ad72a4b/attachment.html>