Re: Deprecating Future's .then()

On 21/05/13 6:53 AM, Tab Atkins Jr. wrote:
> On Mon, May 20, 2013 at 2:24 AM, Sean Hogan <[email protected]> wrote:
>> The accept/reject callbacks in .thenfu() have the same form as the `init`
>> callback in `new Future()`.
> No it doesn't, unless you've changed the proposal since your OP.  The
> callback passed to the constructor receives a resolver as its
> argument.  Your proposal is to set `this` in a thenfu callback to a
> resolver object for the chained future.


My OP stated a secondary change as:

     c. the modification of `new Future(init)` so that `resolver` 
becomes the `this` object of `init`.


>
>> Do you think that form of `init` is not useful?
> I think it's less convenient, but you have to expose a resolver
> directly *somewhere*, and doing so in the constructor works well.  I
> don't think we should aim for making then callbacks the same as the
> resolver callback.


I'm not advocating .then() callbacks being the same as `init` callbacks 
either.


>> So people who want future.then() will want auto-`then`-detection in their
>> init callback and, therefore, resolver.resolve().
>> Fair enough.
> The resolve algorithm isn't about then-detection, it's about
> conditional assimilation - if you give it a Future (or maybe a
> thenable), it'll return a new Future linked to the input that
> completes at the same time and with the same value (in other words, it
> just passes it through, but does a copy as well); if you give it a
> plain value, it returns a new Future that immediately accepts with
> that value.
>
> In other words, it conveniently converts a Future<value>-or-value into
> a Future<value>, so you can operate on both cases with a single code
> path.


Yes I know that. But it only detects "thenables". Obviously it can't 
magically detect every asynchronous response style so it commits to *one*.

`new Future()` and `.thenfu()` callbacks are committed to *none*.


<snip>There's a whole lot of unresolvable argument here, because the 
main misunderstanding seems to be...

>>>> - to my knowledge doesn't compromise the current compatibility with JS
>>>> Promise implementations.
>>> Saying "don't use the Promise properties, they're busted" isn't great
>>> compatibility, and it leaves us stranded in a halfway-land where we're
>>> neither compatible with promises nor Node's async pattern.  I don't
>>> think it can justify itself on its merits sufficiently to overcome
>>> these difficulties.
>> That a big misrepresentation.
> That's exactly what you said, isn't it?  I don't know how else to
> interpret "deprecate .then() and .catch()".


Fine. Ignore the deprecation suggestion. It's just a warning anyway:

"We know this feature will have to be supported for a long time but it 
does have issues and there is an alternative. "