[zeromq-dev] new libzmq API

MinRK benjaminrk at gmail.com
Fri Jan 18 10:34:57 CET 2013


On Fri, Jan 18, 2013 at 12:01 AM, Pieter Hintjens <ph at imatix.com> wrote:

> On Fri, Jan 18, 2013 at 1:16 AM, MinRK <benjaminrk at 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130118/6b47f4a5/attachment.htm>


More information about the zeromq-dev mailing list