On 03/14/2013 11:48 AM, Martin Sustrik wrote:
On 2013-03-14 16:18, Evan Wies wrote:The nn_symbol and nn_get_symbol API make a lot of sense.Do we need two functions? My impression is that once we have a way to list all symbols, bindings will store them in language-specific way and will be able to use native language constructs to convert symbolic name of the constant into its numeric value, i.e. we won't need a special function to do that.I agree that nn_get_symbol accepting an index is better than returning array -- it is simpler all around and allows nanomsg to freely/easily change the internal representation. That said, the bindings I care about can use this technique. Here's some other argument options: // #1 original suggestion int nn_get_symbol( int i, int* value, const char** name ); // #2 this is better if it is challenging for a binding to deal with pointer args // NULL returned if invalid. This is akin to the existing nn_strerror (which IMO should still exist) const char* nn_get_symbol( int i, int* value ); // #3 the simplest const char* nn_get_symbol( int i );I was thinking about #2 as well. Maybe we should go that way just to be on the safe side.Is 'i' in #3 the numeric value of the symbol? If so, it won't work as there are multiple symbols resolving to the same numeric value.
For #3, `i` is the index, as in the other forms. Thus to get the code would be a two-step process: nn_symbol( nn_get_symbol(2)). But, you are right -- two functions are only needed in the case where there is a one-argument form.
Perhaps NN_NUM_SYMBOLS should be one of the symbols and based at index 0? Still, users should probably start at 0 and iterate until rc<0 (or ==NULL in my other suggestions).I would go for error when the end of the table is reached.Here's the LuaJIT binding employing this (using signature #1, but it is easy to change). https://gist.github.com/neomantra/5154954#file-nanomsg-lua-L74 That is much easier than maintaining a list by hand (which you can see by traversing the revisions of that gist).Wow, that looks really elegant. Better than I've expected, actually :)One drawback of this technique is that often "code is documentation", and we lose that with this (for these dynamic bindings at least.) Of course that can be alleviated by having good core documentation (which we do, but would need to add some more).Yep. It is better to spend some time on improving the core documentation than having a copy of all the constants in 30 different bindings. At that scale I would estimate that some 10% of the bindings would be at least partially broken at any single point in time.Martin
All sounds good to me, Evan