[PD-dev] nameclashes

[IOhannes m zmoelnig]

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