[zeromq-dev] Language binding guidelines

[Brian Granger]

Chris,

> 2. I prefer option 2.
>
>        ctxt = ZMQ::Context.new
>        sock = ctxt.socket(ZMQ::PUB)

Other than the socket being named "create_socket" this is what I am
doing with Python bindings.

> This style allow chaining... especially for one-liner.
>
> ZMQ::Context.new(1,1).socket(ZMQ::SUB).connect("udp://eth0:224:0.0.1:5555")... blah blah blah

Hmm, in Python, this usage would not hold references to the socket and
context objects which would trigger the automatic cleanup code.  If
you don't have automatic cleanup code, you have just lost refs and
won't be able to call the cleanup code manually.  Hmm....can you
elaborate ...

> I'm developing a Ruby wrapper on top of rbzmq for more convenient usage in Ruby.  When it's in a usable state, I'll post it here.

That 0MQ API is already pretty minimal and simple, so I am not sure
how it could be made more convenient.  What type of things are you
thinking of?  I might want to include some of them in the python
bindings.

> 3. Ruby, like any GC based languages, needs explicit close/term/disconnect methods for cleaning up resources used.  Even for C++, I'd argue that it's better to avoid relying on destructor 100% for implicit resource cleanup.  It's especially true in Java, the finalizer is not guaranteed to be called upon process termination AFAIK and it's unpredictable when it'd get called.  (Not saying that Java's finalizer is the same as C++ destructor.)

But in a situation like 0MQ, it seems like the greater danger is to
not perform the cleanup by forgetting to call the cleanup method.
Thoughts?

Cheers,

Brian


> Chris
>
> On Mar 1, 2010, at 12:17 PM, Martin Sustrik wrote:
>
>> Hi Chuck,
>>
>>> 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.
>>
>> Yes. That's the same thing. It just renames context to factory.
>>
>> The other piece here is using a different syntax for creating sockets
>> (issue pointed out originally by Brian Granger):
>>
>> s = z.makeSocket (ZMQ::PUB);
>>
>> vs.
>>
>> s = ZMQ::Socket.new(z, ZMQ::REP);
>>
>> So far it seems that people prefer the former.
>>
>>> 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.
>>
>> Right. The problem is that context cannot be completely hidden. The
>> reason why it exists at all is that several instances of 0MQ may get
>> into the same process - think of linking your app with two libraries,
>> each using 0MQ. Having a single global context would make the libraries
>> interfere in unexpected ways.
>>
>> Martin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com