Making Q.set and Q.delete chainable

[thefourtheye]

When I was answering this question in Stackoverflow, I realized that we cannot do something like this

Q({ foo: "bar" }).set("foo", "baz").then(console.log);

Because, set doesn't resolve with the modified object, so console.log would print undefined. Also, this limits the users from doing, something like this

Q({ foo: "bar" }).set("foo", "baz").get("foo").then(console.log);

The intention of this PR is to make set and delete to resolve with the modified object, so that they can be chained in the promise flow.

[bergus]

expect(result).toBe(object) sounds more natural

[thefourtheye]

@bergus Thanks for reviewing :-) I changed it like that.

[bergus]

+1. Nobody needs a promise that resolves to undefined.

[kriskowal]

Deep in the annals of Q, you will find that this backward-incompatible change reverts a backward incompatible change that was made between 0.8 and 0.9. I decided that it would be suboptimal for Q-Connection to be hauling the serialized return value of these methods across the wire. @domenic also expressed distaste for chaining style methods, and I concur.

With the respect due for a proposal to make Q work the way I originally wrote it, this will not land in the v1 branch (because it is backward-incompatible) and probably won’t land in the v2 branch (because it would lead to waste on the wire).

[benjamingr]

@kriskowal just pointing out - the "across the wire" thing can be handled by a second method like:

Q({ foo: "bar" }).set("foo", "baz").ignoreReturnValue()...

Not that it matters as you're super busy anyway on other stuff :)

[kriskowal]

@benjamingr That would not work. The .set() method sends a message, which will arrive before the "ignore" message.

[benjamingr]

@kriskowal not if ignoreReturnValue is called synchronously. The messages set sends are presumably batched anyway so presumably you don't dispatch them "right away" but after a tick - so plenty of time to augment whatever message sent to not return anything from the server but an ack.