Hans-Christoph Steiner wrote:
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces.
this is only half of the truth, as (in your example) [prepend] (without "namespace") will be used after using [cxc/prepend]. so you will have to use the namespace mechanism throughout your patches. (think compatibility)
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
ahem, what are you talking about really ? the cvs is a collaborative code base where people can check in whatever they produce. as soon as anyone will start kicking out off/renaming objects within a library (e.g. zexy) i will consider this as censorship, being a hard violation of "free as in speech".
who will decide which "prepend" is the most simple and robust ? and who will pay for fixing up patches ?
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
actually i think that flags would be great to acchieve compatibility between different solutions of the namespace-problems.
|- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name
actually i really think this would solve most of the problems: using both(!) directory structures and automatic library/object naming (from within pd - which i have suggested years ago).
no flames intended.
| |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable)
well, i guess the flag-syntax has to be carefully thought off to come over the cons.
|- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above
i don't see how this should work. generic feature testing of objects ? i wonder, how you do that
mfg.a.sdr IOhannes