Re: Deprecating Future's .then()

Sean, this is quite clever.

Hi Tab, I'm glad that you're happy either way because I'm happy only one
way ;). Actually, this is an issue that we've already discussed over in Q
land.

In Q and in the Q style, a promise broken by a promise is not weird at all.
It wouldn't make sense to do anything like flattening this. The outer
promise, being broken, will never designate a value. The inner promise is
not there to designate the value that the outer promise designates. Rather,
the inner promise represents the reason explaining why the outer promise is
broken -- why the outer promise will never designate anything. The inner
promse might for example be a promise for an Error. If the inner promise is
pending, then we still know the outer promise is broken, but we don't yet
know the reason why.

    outer.then(onFulfill, onReject)

must invoke onReject(inner), passing the inner promise as the reason,
without waiting for the inner promise to resolve.



On Wed, Jun 5, 2013 at 5:56 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Jun 6, 2013 at 9:51 AM, Sean Hogan <shogun70@westnet.com.au>
> wrote:
> > Should the spec continue to allow this behavior?
> >
> > or ...
> >
> > Should the resolve algorithm - which is currently infinite unwrap for
> > accepted / fulfilled futures - also be infinite unwrap for rejected
> futures?
>
> I'm satisfied with either behavior.  It might be nice to have it
> mirror the then/chain behavior, where it fully-unwraps or
> single-unwraps as appropriate, but I'd likely be fine with both doing
> single-unwrapping or both doing full-unwrapping.
>
> ~TJ
>



-- 
    Cheers,
    --MarkM