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

[Alexandre Torres Porres]

regarding a workaround between zexy's <~ and cyclone's I can also think of
a workaround

in Max/MSP there are alphanumeric versions of those objects, such as
[greaterthan~]. So they can be compiled as single objects, allowing someone
to specify it as cyclone/greaterthan~ if needed/desired.

these would solve clashing issues I found with cyclone and vanilla/zexy

but other overwritting potential issues remain

cheers

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

> 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/ca4b427a/attachment.html>