On Fri, Mar 12, 2010 at 7:26 AM, Jeremy Orlow wrote: On Fri, Mar 12, 2010 at 3:23 PM, Jeremy Orlow <jor...@chromium.org> wrote: On Fri, Mar 12, 2010 at 3:04 PM, Kris Zyp <k...@sitepen.com> wrote:
>> I believe computer science has clearly >> observed the fragility of passing callbacks to the initial function >> since it conflates the concerns of the operation with the asynchronous >> notifications and consequently greatly complicates composability. >> I don't understand this sentence. I'm pretty sure that you can wrap any >> callback based API in JavaScript with a promised, differed, etc based API. >> As >> Nikunj mentioned earlier, we're more concerned about creating a small >> API surface area and sticking with well understood API designs rather than >> >> eliminating the need for libraries that wrap IndexedDB. Trying to digest this thread, I think we've sort of gone full-circle with the whole promises thing. When looking at the code with the chained "then" pattern I just love the result, but it seems that we can't get all the way there (and nesting instead of chaining stuff kind of lacks the magic). My take is that either we get the really nice pattern by going all the way or we create a more traditional callback/events-based API and then we build promises on top. Things seem to indicate that frameworks are still cooking on promises, so it may be safe to stay with callbacks/events and just build libraries on top (I would have loved to have this be the thing that saved us from needing a library always...but it seems we'll fall just a bit short). As for callbacks versus events, while now I'm starting to get used to the events hooked up to the result object after the call, the callbacks may be a more natural mechanism for this particular usage. I'm not sure why this is fundamentally broken...would love to see examples or reference. If that's the case, then events are the obvious choice. Thanks -pablo
