Marc Boon wrote:
Johannes M Zmoelnig wrote:
- this keeps me from having nameclashes on my machine: for instance i
am using Gem a lot (no-na) but i don't want it in my .pdrc for testing purposes; using Gem+maxlib would result in the famous [scale]-problem which i am not very interested in (i mean: i am interested in the problem but not in having it) 3) thus i didn't know that the others existed. (even though it might seem strange that i did not realize that there was one in the iemlib)
These two points clearly illustrate the need for namespaces in Pd. Like every other OO programming language, Pd would greatly benefit from namespaces, like <package>.<object>. Then, for example, zexy.wrap would be a different object than iem.wrap, and there would not be any name clashes.
Not only would this avoid nameclashes, but it would also help when I get a patch in the mail or from the archive, and it doesn't include docs as to which libs it is using. Even after I've compiled what appears to be all the externals, and have copies of what seems to be all the commonly-used abstractions, I still get unmade objects when trying out stuff I find on the web, and usually that means Googling around to see where to get the missing parts.
AFAIK, though, you *can* specify [maxlib_wrap] or [iem_wrap], because they actually *do* do different things, and have caused me much grief in the past ;-) This convention is not commonly used, however, except in the rare cases where people know there is a nameclash and intend to publish their patches.
How to implement this while keeping backwards compatibility with old patches will be the trick, here.
best, d.