On Nov 16, 2009, at 5:55 PM, Claude Heiland-Allen wrote:
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~]?
I think that relying on the namespaces alone could make for confusion
if you want to use tabplay~ along with fstabplay~.
Is [import] not yet good enough?
[import foo] just loads a lib as if you did "pd -lib foo" or however
you do it with [declare].
Missing a feature like [import framesync as fs] to use [fs/tabplay~]?
I think that python's import is much too complicated for Pd. I spent
a long time wading thru all of the relevant discussions, code, and
docs that I could find and put it in my PdCon3 paper. I would love to
have feedback on the details of that paper rather than just
reiterating bits of what's there.
http://at.or.at/hans/Let's_Make_Libraries_-_PdCon3.pdf
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..
Yeah, I also try to avoid globals as much as possible. With this
library, its kind of mirroring the audio clock of tilde objects, so
[fps] is like [samplerate~] and the frameclock is transparent, just
like you don't have to tell tilde objects which audio clock to use. I
am trying to address situations when you are scoring to a video. I
can't see a time when you would have to deal with multiple video
framerates within the same project.
I want to avoid having all this as arguments, since some of the
objects already have 4 arguments. But I am open to suggestions to how
else to deal with this. It would be nice to have the frame clock and
fps within a project namespace, I just can't think of a way to do it
without making things too complicated.
.hc
----------------------------------------------------------------------------
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
