> > #3: If we go this route, #2 would be moot. But the two behaviors are not > > exactly the same. For Object, you specify a timeout of 0 if you want to > wait > > indefinitely, and -1 is illegal. For Poller, -1 means wait indefinitely > and > > 0 means "wait at most a very short time". We would also have to define > how > > to deprecate Poller.[gs]etTimeout(). Ideas? > > Why not have two branches of jzmq like with zmq itself?
My question was more "do we use Object's convention of 0 for indefinite wait, or do we keep -1 for that?" But now I realize that this is defined in 0MQ itself, so never mind. > E.g. maint (tracking 0mq/maint, maven/ivy/etc version 2.0.10) and > master (tracking 0mq/master, maven/ivy/etc v2.1.0). That way you could > mark getTimeout/setTimeout as @Deprecated in maint and remove them in > master. The only reason for this is that I am too (git-) ignorant / lazy / both. Perhaps, as Martin S. suggested, we could handle this with version numbers. Alternatively, I am not really afraid of breaking backwards compatibility. In this case, what if we do this: 1. Initialize this.timeout to -2. 2. Deprecate [gs]etTimeout(). 3. Only allow setting this.timeout to a value >= -1. 4. If poll() is called with no args and this.timeout is == -2, poll indefinitely (new behaviour). 5. If poll() is called with no args and this.timeout is != -2, poll using the value of this.timeout (old behaviour). 6. If poll() is called with args, use those args as the timeout value and don't even touch this.timeout. Opinions are welcome. -- Gonzalo Diethelm _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
