[PD-dev] namespaces for send/receive

IOhannes m zmölnig zmoelnig at iem.at
Mon Nov 16 23:40:24 CET 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans-Christoph Steiner wrote:
> 
> On Nov 16, 2009, at 3:10 PM, zmoelnig at iem.at wrote:
> 
>> Quoting "Hans-Christoph Steiner" <hans at at.or.at>:
>>
>>>
>>> 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~]  the internal
>>> send/receive  would be [send framesync/fps] and [receive framesync/fps].
>>
>> while you are there, i would propose to use "/foo/bar" rather than
>> "foo/bar".
>>
>> while this doesn't fully match the [foo/bar] idiom for object-names,
>> it does fit nicely into OSC.
> 
> Hmm, I guess that's a parallel.  I personally never use OSC, so I don't
> see a reason to follow its syntax instead of Pd's syntax.  Since the
> foo/bar syntax is already there, I think its best to stick with it for
> Pd.  Then for people who use OSC, it would be an easy translation.

why do you want a translation, if there is no need for one?

> 
> Plus wouldn't OSC namespaces follow the project rather than a library? 
> I guess if you use OSC in a library, then it would follow the library.
> 

right, let the user examine whether the lib uses OSC somewhere
internally, and then they will figure out whether to prefix / or not :-)

it's open source after all

mgare
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksB1NgACgkQkX2Xpv6ydvQJ/ACg1lsJotdkzB+CC28WobebfjU8
QBMAmwYJW8yvSIVi3qCrZYSQAJYY3d/D
=sq0u
-----END PGP SIGNATURE-----




More information about the Pd-dev mailing list