Dean Landolt wrote: > On Tue, Mar 29, 2011 at 11:58 AM, Scott Sauyet <[email protected]>wrote:
>> I still think you need to work out the API you would like, perhaps >> something like this would be a good start: > >> Lib: >> when(/*Deferred*/ dfd): Promise > >> Deferred: >> promise(): Promise >> resolve(/*Whatever*/ args): void, calls 'then' listeners >> reject(/*Whatever*/ args): void, calls 'fail' listeners > >> Promise: >> then(/*Function*/ fn): Promise, will fire on resolve >> fail(/*Function*/ fn): Promise, will fire on reject > >> [ ... ] >> That is, I believe, a simplification of jQuery's API. Is this the >> type of code you're trying to include in your library? > > Well, not quite. The fail method is redundant as the then method is spec'd > to take both a success and failure callback Right, I was describing a simplification of jQuery's API, not an implementation of the Promises/A, Promises/B, Promises/KISS, or Promises/D proposals. In the jQuery API, they did eventually add the failure callback parameter to ".then()". Was the progress callback eventually added, do you know? But the API works fine without it, and for a simplification for someone unsure who's trying to start an implementation, it seemed reasonable to include only the success handler for the first pass. Honestly, though, I prefer jQuery's "then/fail" to the single method of Promises/A. I'm less convinced by jQuery's "done". > Also, I'm not quite sure what you're doing with when here, > but it should take a static library fn, not an instance method. Yes, I was thinking of Lib as a namespace singleton, just there to avoid having 'when', 'Promise', and 'Deferred' cluttering up the global namespace. -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
