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 >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >> >> >> -- >> Brian E. Granger, Ph.D. >> Assistant Professor of Physics >> Cal Poly State University, San Luis Obispo >> [email protected] >> [email protected] > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
