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

Alexandre Torres Porres porres at gmail.com
Wed Apr 6 19:51:51 CEST 2016


it's cool cyrille, sorry if I was too upset and harsh by the way :)

Well, I actually seem to have found a trick... testing it right now! Stay
tuned...

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

>
>
> Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
>
>>
>>
>> 2016-04-06 7:11 GMT-03:00 cyrille henry <ch at chnry.net <mailto:
>> 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.
>>
> oups, sorry.
> right. it did create one more problem between extern and intern.
> it look like cyclone and vanilla dis not mix well together.
>
>
>
>> 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!
>>
> yes, right.
>
> according to the mailing list, this feature was introduce in vanilla 0.42,
> and was briefly discuss 6 years ago.
> i did not find any other reference in this list since.
>
>
>>     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.
>>
> its a good thing to raise - and solve - issues.
>
>
>>     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.
>>
> and i understand why you are upset with things been 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
>>
> ok, i'm sorry i could not help.
>
> cheers
> c
>
>
>
>
>> I still do not see any advantage in object overwritting, and I see how it
>> is causing name clashes.
>>
>> cheers
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160406/eb24aa50/attachment-0001.html>


More information about the Pd-list mailing list