On 9/29/06, sky <[EMAIL PROTECTED]> wrote: > > 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
So why can't these return the object they get? > 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. I don't understand what you mean by "have been triggered already". I don't see how signals wouldn't be appropriate here. One gigantic problem with your branching proposal is that errors get thrown away silently with no opportunity to catch them (unless error handling is in every callback). -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 -~----------~----~----~----~------~----~------~--~---
