[zeromq-dev] Language binding guidelines

[Brian Granger]

Chris,

> Different style in naming.  I prefer to keep it more Rubyist.  If create_socket is common in Python, it's perfectly good that way.

I might end up going with "socket" as well depending on how others
like you go on this one.  I do think it is important to try to stay
somewhat close to the other bindings.

>> 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.
>>
>
> I'd avoid repeating myself later.  Look for an email in a couple days from me on my Ruby library.  I'd include a couple examples to demonstrate both.

OK, great.

>>> 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?
>>
>
> It doesn't hurt to have the cleanup code in the destructor *also*, but it shouldn't be the only place IMO.  One may choose to manage the lifetime of the "socket" resource explicitly in C++.

Yes, that makes sense.

Cheers,

Brian

> Chris
>
>> 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
>
>



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