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

[Alexandre Torres Porres]

Here's a workaround to call [cyclone/line~] in pd-vanilla without
overwritting vanilla's [line~]

First, a little history...

Seems cyclone was first designed with First Capital letters object names to
avoid name clashing, such as [Line~], this was present in Extended up to
version Pd-Extended 0.42-5 (cyclone's version was then 0.1alpha 55).

In Pd Extended 0.43 (and cyclone 0.1 alpha 56), cyclone also included two
aliases for Line~ and other name clahsing objects, so it could instantiate
also as only "line~". But the thing is that vanilla's [line~] would have
priority and never be overwritten. Using [cyclone/line~] here would allow
you to call cyclone's [line~] without screwing with vanilla's.

What I found out is that cyclone, in this version, also carries another
alias "cyclone/line~"

this does not call a line~ object inside the cyclone folder, but calls
"cyclone/line~" inside cyclone.

So I supressed the "line~" alias and kept me with "Line~" (original object
name) and "cyclone/line~" (alias), then tested on vanilla 0.46-7 64 bits
and 32 bits.

Now, if I call [Line~] on vanilla, it loads cylone's line~ without
overwritting vanilla's [line~]. And I can also call it as [cyclone/line~]
that vanilla's [line~] keeps intact and not overwritten!

I tested the same compiled object in Pd Extended 0.42-5 (I don't use 0.43)
and it worked fine as well.

Thus, a quick immediate fix for this is changing the alias inside
cyclone... seems like a workaround, but doesn't look that good I have to
say...

Besides cyclone, I don't know why anyone else would create externals with
the same name as a vanilla internal...

I still think that overwritting and renaming to "x_aliased" is not a good
idea.

The incapacity to specify objects inside regular libs is an old thing, I
think it could be a nice feature request.

cheers

2016-04-06 14:51 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 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/74a66697/attachment-0001.html>