Set does not support writing flags about memjs HOT 9 CLOSED

Yes, flags are a pretty useful feature. It's on the TODO (in README.md) list but I never got around to it, thanks for the kick in the butt

from memjs.

Yeah, what am I paying you for? :-)

from memjs.

OK, I'm looking at doing this right now. The biggest question is where should the argument go such that I don't break people's existing code in some hard to debug way. The current signature for set is:

set(key, value, callback, expires)

Where expires was added at the end specifically for this reason. An obvious option is to stick flags at the end again, but this starts to seem ugly (why isn't the callback last?). Two alternatives come to mind:

1. Phase out the current interface and opt for a jQuery dictionary style argument to set et al.
2. Do the hack where we look at the type of the arguments and use that to simulate method overloading.
3. Some combination of (1) and (2) where we support the legacy interface by looking at the types, but if the first parameter is a dictionary, use (1) instead.

Thoughts? Other suggestions?

from memjs.

You haven't reached 1.0 yet so breaking charges are still allowed. 1) seems the cleanest, but you can try 3) with a deprecation warning if a dictionary isn't used.

from memjs.

OK, I buy that. People are using it in production, nontheless, so I'd rather not totally break API, but 3 with a deprecation warning makes sense. Does a dictionary in fact seem like a decent API? In jQuery, for example, they use that API under the hood, but have higher level functions take regular arguments. I suspect because the dictionary can be cumbersome for sequencing callbacks...

from memjs.

And be aware that npm gets you new versions by default. Not everybody is disciplined enough to npm shrinkwrap and what not.

from memjs.

Most of the other libs I've used take a dict options = {some: 'some', dict: 'dict'} for the initial setup, i.e., new winston.transports.File options and sometimes have it as the first argument, i.e., request options callback. Can you give an example of how callback sequencing gets cumbersome?

from memjs.

Ah, no that seems fine. At the moment newer arguments have been stuck on after the callback to maintain backwards-compatability. The way you are suggesting doesn't make chaining harder at all

from memjs.

Duplicate of #53

from memjs.