[PD] nameclashes

[Marius Schebella]

I know that the pd fileformat does not allow comments or headers. But I was 
thinking of a declaration in a header like "from iemlib import gate" and all 
gates in the patch would be iem ones. I dont like the idea of typing 
iem::gate all the time and I think it may be easier to define the object at 
the beginning of the pd file than replacing the text of every object. And 
you could use different library objects in different abstractions.
Apart from that, I think, communication is best. Is there a list of all 
problem objects until now? i think also the capital letter-cyclone objects 
are problematic, because of the help-patches, which are not displayed 
correctly under windows.

Append (pd native, cyclone)
Clip (pd native, cyclone)
Line~ (pd native, cyclone)
Snapshot~ (pd native, cyclone)
Scope~ (pd native, cyclone)
gate (iemlib, cyclone)
prepend (iemlib, cyclone)
split (iemlib, cyclone)
and I think there are some cyclone dummies, which will be objects in the 
future (?). like sfplay~.

btw. arent there also problems with abstraction nameclashes?

marius.


----- Original Message ----- 
From: "Tim Blechmann" <TimBlechmann at gmx.net>
To: <pd-dev at iem.at>
Cc: <pd-list at iem.at>
Sent: Thursday, November 04, 2004 11:19 PM
Subject: [PD] nameclashes


> 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
>
> -- 
> mailto:TimBlechmann at gmx.de    ICQ: 96771783
> http://www.mokabar.tk
>
> After one look at this planet any visitor from outer space
> would say "I want to see the manager."
>       William S. Burroughs
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>