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
--
http://claudiusmaximus.goto10.org
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
