Bob Ippolito wrote:
> Do you remember why you thought the value or exception was passed on
> unchanged? How can the documentation be improved to prevent this
> misinterpretation?
I admit that I didn't read the documentation thoroughly on my first
pass. In reading the first paragraphs, a Deferred() sounded like an
observer pattern that had the added value of keeping its last
value/status around if anything else wanted to "run this now if it's
ready, or run it later, when it is." Perhaps you could change the
first para:
Encapsulates a sequence of callbacks in response to a value that
may not yet be available. This is modeled after the Deferred class
from Twisted [3].
(the 'in response to a value' does feel like the callbacks are
connected to that *one* value)
to something like:
Encapsulates a chain of callbacks that begin when a value becomes
available.
This is modeled after the Deferred class from Twisted [3].
(language from
http://twistedmatrix.com/projects/core/documentation/howto/defer.html)
> 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.
Two similar situations come up when I want to use it this way.
1) When several things are going to change on the page that are
triggered from a loadJSONDoc or other xmlhttprequest. Most of them
aren't reliant on each other but on the original jsondoc
2) I'm working on a video/clipping library, where there's a Media
object. I want to keep the loading/playing of media abstracted, so
other code can update when the media has loaded or begun playing. Of
course, sometimes, the media is already loaded (when it was cached or
there's a fast connection, e.g.). But all of these things should hang
on the original Load or Play. I had implemented a media.onload object
as a Deferred, so code outside the library could addCallback or
addErrback (an example of an outside errback on the video library is
doing something particular if the Flash/QT version isn't good enough).
In both of these, signal/connect aren't what I'm looking for, because
the event may have been triggered already.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~----------~----~----~----~------~----~------~--~---
