[PD-dev] nameclashes

[Hans-Christoph Steiner]

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.  Abstractions work with this 
namespace as well.  Check the attached set of patches to see it in 
action.

I was thinking of doing this with a couple of sets of objects for the 
distros.  For example, having a folder called "cyclone" with all of the 
cyclone objects, which would only need to be used when porting a Max 
patch.  The good objects from cyclone should be part of the main 
distro, like [prepend].  The other one I was thinking of making is 
"deprecated", for objects that aren't really useful anymore, but old 
patches might use them.  For example, after I release the [hid] stuff, 
then the [linuxmouse], etc. stuff would be deprecated, since [hid] does 
everything they do, does it better, and does more.

.hc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: namespaces.tar.bz2
Type: application/octet-stream
Size: 3800 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20041105/9d639861/attachment.obj>
-------------- next part --------------
   (one included obj is compiled Darwin)

On Nov 4, 2004, at 3:39 PM, d.lj wrote:

>
> hy
>
> 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".
>
> 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.
>
> bst, opt
>
> [Tim Blechmann]->[[PD-dev] nameclashes]->[04-11-04 23:19]
>
>  |hi all ...
>  |
>  |i'm currently thinking of a way to solve the nameclash problem  
> (counter,
>  |scale, prepend, gate...)
>  |
>  |here are some suggestions for a solution ... with some pros and cons:
>  |
>  |- 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
>  |
>  |- 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)
>  |
>  |- communication: figure out, if the external name is already in use
>  |  pros: - no implementation effords
>  |  cons: - not really working (that's why we've got these problems  
> *g*)
>  |
>  |- 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
>  |
>  |personally i'd prefer the communication in combination with a startup
>  |flag ... but i'm curious about other ideas or comments ...
>  |
>  |cheers ... tim
>  |
>  |
>
> --  
> x          ?          v          .          o          7          g
> GPG-key at http://xdv.org/~jdl/jdl.pub.asc
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>

________________________________________________________________________ 
____

            "The arc of history bends towards justice."
                                                               Dr.  
Martin Luther King, Jr.