[nanomsg] Re: RFC: Error code query API
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: <nanomsg@xxxxxxxxxxxxx>
- Date: Thu, 14 Mar 2013 16:48:58 +0100
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.
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
Other related posts:
