[PD-dev] namespaces for send/receive

[Hans-Christoph Steiner]

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++)