Hans-Christoph Steiner wrote:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~]
Why not call it [framesync/tabplay~]? Is [import] not yet good enough? Missing a feature like [import framesync as fs] to use [fs/tabplay~]?
the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
.hc
Personally I'm not a fan of globals(*) - better for the user to tell the objects explicitly what name they should use to share information, thus letting more than one instance of the library functionality be used in the same instance of Pd.
So, my suggestion would be to use the first argument (or other easy to remember convention) to be the namespace to use for communication: if the user really wants a global they can use [framesync/fstabplay~ fs] and if they don't they can use [framesync/fstabplay~ $0].
The three extra characters " $0" are hardly a huge burden, but the benefits can be large imho.
But yes, if globals *must* be used, then using a global name closely related to the name of the library seems sensible.
(*) Pd has no non-globals, just obfuscated names..
Claude