On Wednesday, February 15, 2012 at 4:50 PM, Pieter Hintjens wrote:
> On Wed, Feb 15, 2012 at 6:41 PM, Aurélien Vallée
> <[email protected] (mailto:[email protected])> wrote:
> > Just my 2 cents:
> > get/set are easy to remember, while peek/poke are... kind of weird
> >
>
>
> Yes, in the memory of 6502 programming. But get/set by themselves
> aren't enough, there has to be an object, making it a clumsy function
> name. zmq_ctx_getoption or zmq_ctx_getopt or whatever.
>
> If peek/poke still feel too weird after a while, we can switch to
> getopt/setopt. It's a simple patch.
>
> I'm using the same nomenclature for zmq_msg_peek/poke, would send that
> pull request but github ssh access is down at the moment.
>
I don't really often have reason to speak up here, but, peek and poke really
bother me.
I think the kind of structure they imply (for those of us not fortunate enough
to do 6502 coding), is something somewhere in the "spectrum" of: streams,
stacks, queues, and
registers.
While, one could make the argument that zmq_ctx_peek(ctx, ZMQ_IOTHREADS) might
be
close to a "register" per-se. I still, when thinking about it, imagine that it
has something
closer to do with a stream or stack, and thus, when looking for something to
get and
set options, I would overlook them in my first couple of passes through the API
docs.
On the other hand, even lacking an object following them, "get" and "set" and
set are
"pretty standard" nomenclature. Meaning, that when I read "zmq_ctx_get(", the
next thing
I expect is the subject of get (linguistically speaking). And, further, when
I'm working in C,
I also usually expect to ignore the first argument, since that's typically the
"self" object.
Obviously, this is bike shedding, but, FWIW, I think 0mq has historically done
pretty well
when it comes to the linguistic design of the API. When looking for how to do
something,
I've never found myself scratching my head looking for something that "reads
right".
It's always been my first pick.
-B
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
