Sam Tobin-Hochstadt wrote:
> On Sat, May 25, 2013 at 1:30 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> Sam Tobin-Hochstadt wrote:
>>> In the meeting, there were (a) people advocating for styles of
>>> programming along the lines that you (Tab) have put forward, like me,
>>> (b) people advocating for Q-style programming, like Mark, Yehuda, and
>>> Tom, and (c) genuine concern about the complexity budget of the
>>> promise API, expressed most by Luke Hoban, but felt by all of us. Were
>>> it not for this last concern, I think AP2 would have seemed more
>>> attractive.  But since the set of methods available on Promises
>>> themselves is the most visible part of the API, and AP2 doubles its
>>> size, that told heavily against AP2.
>> AP2 from Mark's slides:
>>
>> AP2 (Based on Tab’s latest)
>> • Q.fulfill // lifting
>> • Q() // autolifting, resolve
>> • p.then // deep flattening
>> • p.flatMap // “chain”
>>
>> AP3, next slide:
>>
>> AP3
>> • Q.fulfill // lifting
>> • Q() // autolifting, resolve
>> • p.then // deep flattening of returned value
>>
>> There's no doubling, just 4 methods instead of 3.
>
> This is twice as many methods on promises themselves: `then` vs `then`
> and `chain`.

Oh, *methods* :-P.

I'm an FPer at heart, can you tell?

>   Many more people will consume the promise datatype than
> produce it, which mean that this does double the methods that
> consumers need to know about.

Either they need to know about one method and the {value: x} hackaround, 
which is needed sometimes; or they need to know about two methods, then 
and chain. Which is worse? You could argue the {value: x} hackaround is 
rarely needed, but the same argument can sell chain too. I just don't 
see how bean-counting is the right way to assess here.

The problem {value: x} solves is real, no one dismisses it. In arguing 
about how to enable developers to solve it, we should count all the 
beans and try to assign weights to them. My weighted counting favors a 
second method over a manual wrapping pattern. Tab made this point 
already in arguing that then + chain is not a union of designs, any more 
than then + {value: x} is unioning in the bad committee-designed sense. 
 From everything you wrote, though, it sounds like TC39 people just 
bean-counted methods. Boo...

/be

Sam Tobin-Hochstadt wrote:

> This is twice as many methods on promises themselves: `then` vs `then`
> and `chain`.

Oh, *methods* :-P.

I'm an FPer at heart, can you tell?

> Many more people will consume the promise datatype than
> produce it, which mean that this does double the methods that
> consumers need to know about.

Either they need to know about one method and the {value: x} hackaround, 
which is needed sometimes; or they need to know about two methods, then 
and chain. Which is worse? You could argue the {value: x} hackaround is 
rarely needed, but the same argument can sell chain too. I just don't 
see how bean-counting is the right way to assess here.

The problem {value: x} solves is real, no one dismisses it. In arguing 
about how to enable developers to solve it, we should count all the 
beans and try to assign weights to them. My weighted counting favors a 
second method over a manual wrapping pattern. Tab made this point 
already in arguing that then + chain is not a union of designs, any more 
than then + {value: x} is unioning in the bad committee-designed sense. 
 From everything you wrote, though, it sounds like TC39 people just 
bean-counted methods. Boo...

/be