[zeromq-dev] Language binding guidelines

Chuck Remes cremes.devlist at mac.com
Mon Mar 1 19:04:00 CET 2010


On Mar 1, 2010, at 11:51 AM, gonzalo diethelm wrote:

>>>> z = new ZMQ ();
>>>> s = z.makeSocket (ZMQ::PUB);
>>>> 
>>>> z = new ZMQ::Context ();
>>>> s = new ZMQ::Socket (z, ZMQ::PUB);
>>>> 
>>>> My preference is for the latter. Two reasons:
>>>> 
>>>> 1. It's the current way it is. No need to change the API.
>>>> 2. It's more obvious what's going on. The former example is a bit
>>> cryptic.
>>>> However, feel free to outvote me!
>>> 
>>> I think I lean more to the former, for a single reason: in the
> latter,
>>> you must expose your Context object (z). Also, see below (*).
>> 
>> By more straightforward I've meant that you have a single namespace
>> (it's really a namespace, it's never instantiated!) that everyting is
>> placed into: constants, context, socket, poller etc.
>> 
>> In former option the things are a bit confused. There's a namespace -
>> but, interestingly, it can (and must) be instantiated and serves as a
>> context for sockets. Thus, identifier ZMQ actually refers to two
>> distinct things - namespace of the library and context the sockets are
>> instantiated in.
> 
> You are right. Although I am not sure about the consequences of mixing
> the namespace and the instantiated context; probably I have been
> programming in Java / C++ for too long...

For the Java and Ruby cases, why not move to a factory pattern where a class method instantiates and returns an object containing the context and all of the other bits?

// Java
z = ZMQ.factory();
s = z.makeSocket(ZMQ::PUB);

# Ruby
z = ZMQ.factory
s = z.make_socket ZMQ::PUB

This way there isn't any confusion about instantiating what looks like a namespace. 

I must say I prefer the hiding the context away. Whenever I am made to pass the same parameter around I usually write a wrapper class for it anyway just to handle it for me.

cr



More information about the zeromq-dev mailing list