On Fri, Jan 18, 2013 at 12:01 AM, Pieter Hintjens <p...@imatix.com> wrote:
> On Fri, Jan 18, 2013 at 1:16 AM, MinRK <benjami...@gmail.com> wrote: > > > For instance, what would we do if there ever needs to be a context option > > that isn't an int? > > In theory, using macros and a single function makes it easier to write > generic code; in practice since the property types are not consistent, > it's not worth much (and is actually nasty since it hides different > function signatures under a single one). > > So I'd probably go with one function pair (get/set) per option, with > explicit arguments and return types, as we do in CZMQ. It's not much > harder to build the API and it's significantly nicer to use. > > We started this experiment with the zmq_msg_more() function. This is > what I'd do for context properties that aren't ints. > Hm. As a binding maintainer, a proliferation of functions to wrap sounds pretty bad to me. But if zmq_FOO_get/set only deal with ints, and non-int options remain as fairly rare as they have been, maybe them getting their own functions isn't so bad, but it wouldn't be super consistent But if you are talking about a zmq_socket_set_FOO for every single socket option, I am -(uint)(-1) on that. In all, I'm no longer convinced there really is a better situation on this particular issue than what we currently have, because every approach has its drawbacks. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
