-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
On Nov 16, 2009, at 3:10 PM, zmoelnig@iem.at wrote:
Quoting "Hans-Christoph Steiner" hans@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