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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
