Brian, Chris, Chuck,
>> 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.
There was a good point raised by Martin Lucina yesterday, namely that
all the unctions mimic the names used by C API, meaning that developer
in whatever language can check C API documentation (man pages) with
ease. create_socket would be the only exception, not mapping directly to
zmq_socket. On the other hand, zmq_socket cannot be changed to
zmq_create_socket as C API tries to mimic BSD socket API with its
'socket' function.
>>>> 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.
C++ invokes destructors automatically and immediately. If you want to
avoid strict scoping for the object you can allocate it dynamically:
{
ctx = new zmq::context_t (1, 1);
...
if (...)
delete ctx; // destructor is called here
...
} // instead of here
I prefer it this way as it doesn't require handling brain-dead objects.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
