On 9/29/06, sky <[EMAIL PROTECTED]> wrote:
>
> I realize I've been using Deferreds incorrectly, assuming that ALL
> addCallbacks() get called based on the original d.callback() or
> d.errback(). Instead (as most of you know presumably), an addErrback
> that doesn't throw an error itself will continue down the chain, and if
> a addCallback function returns results they won't be available down the
> chain.
Do you remember why you thought the value or exception was passed on
unchanged? How can the documentation be improved to prevent this
misinterpretation?
> Is anyone else interested in something like a deferred 'branch', where
> it won't change the deferred's fired status or return value? One
> implementation could look something like the following (simplified
> because the functions below wouldn't accomodate the automatic partial
> if addCallback, etc. has more than one argument)
>
> Deferred.prototype.addCallbackBranch(func) {
> var self = this;
> self.addCallback(function() {
> func(arguments);
> return arguments;
> });
> }
> Deferred.prototype.addErrbackBranch(func) {
> var self = this;
> self.addErrback(function(err) {
> func(arguments);
> throw err;
> });
> }
In my experience, this comes up pretty rarely. If I'm writing a
callback that shouldn't change the result, then I make sure I write
the callback in a way that doesn't change the result...
Do you have any examples of code that would benefit from this? Passing
through a result or error in a callback is always just "return arg;"
or "throw err;" -- not really a big deal.
-bob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~----------~----~----~----~------~----~------~--~---
