On Jan 9, 2009, at 2:02 PM, Frank Barknecht wrote:
Hallo, Daniel Aschauer hat gesagt: // Daniel Aschauer wrote:
I committed my external to the svn.
But I then realized that in the 0.40.3 extended pd version that I downloaded there is an external (flatspace) included that has similar object with the same name. How are these name conflict processed, and can they be resolved. There should be different object with the same name, right?
There can be no two objects with the same name! :(
To avoid nameclashes, there are several ways. You can compile your objects as single externals instead of a library, put them in a directory "algocomp" and load them as [algocomp/map] etc. Basically you rename your objects then to include "algocomp/" as a prefix. This also requires certain things with regard to help files etc.
You can use [import algocomp] then if you install the "import" external and make your users install it, too.
Or you can chose a different object name on the source code level. For example rename your objects to "ac_map" or "algo_henon" or whatever scheme.
That's what I would do, it's the solution with the least hassles.
Btw.: You maybe want to rename your help files to "NAME-help.pd" as that's the usual standard now. (I only checked algocomp from your site, sorry if you made changes for the SVN version)
Btw++: [map] is a bit superflous: Its functionality is also available as [maxlib/scale], [range] and in many abstractions. I'd just drop it or replace it with an abstraction.
"map" is a little vague, but it is totally workable if you use namespaces like 'algocomp'. But it is a good rule to try to avoid using existing names, and to try to describe the objectclass as well as possible.
Definitely use "NAME-help.pd" for help patches.
.hc
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers