Hi Rich -
These are class-level selectors and function pointers only, no? It seems like an acceptable limitation to me that symbols relative to a static class definition be unique across the memory space. There is a similar limitation in the obj-c runtime, not nice but that's just part of the language.
The part that seems like it would cause a great deal of confusion would be things like send and receiver names, table names, etc. How difficult is it to make these per-instance and deal with classes as static objects that need to use sys_lock() to ensure thread safety? I realize this may not suit every use case, but it seems like this would still greatly improve the feasibility of using pd as a plug-in.
I think this won't work - if you have duplicate symbols flying around in the same instance for the same strings someone will test s1 == s2 somewhere and fail to see a match. I don't think it's feasible to have two symbol types, one for selectors and another for all other names, because you never know when a symbol is being created which of the two it's going to be.
As a second alternative, I was wondering if it isn't possible to prepend a unique per-instance arg to symbols like the ones mentioned above. Of course has threading issues that would need to be resolved...
This is an interesting possibility. I found 48 calls to pd_bind() so presumably I'd have to make 48 edits to prepend a string to every symbol that anything binds itself to. The tricker thing would be message boxes - binbuf_eval() would probably have to do the same prepending when passing messages to named objects from message boxes. (Unless we were just to blow that off and require using explicit "send" objects instead which you'd have to do anyway as it is now, since everything now has to be "$0" - protected.)
cheers Miller