On Tue, Mar 29, 2011 at 1:33 PM, Scott Sauyet <[email protected]>wrote:

> 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.
>
>
jQuery's API is an implementation of Promises/A -- and it extended it a bit.
So, one you simplify jQuery's API what you end up with *is* Promises/A
-- the smallest possible surface area specified.



> 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 don't know if they ever added the progress callback -- I doubt it. But
yeah, sure the API works fine without it -- that's my point. The fail method
isn't a simplification of the API, it's a complication. Perhaps one you
like, but it adds to the surface area. Like I said, it's redundant.


> I'm less convinced by jQuery's "done".
>

Yeah, it's pretty sloppy.


>
> > 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.
>

Gotcha. I see now -- for some reason I read it as hanging off the Deferred
the first time around. But ugh, jQuery really made a mess of when.

-- 
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]

Reply via email to