On Nov 16, 2016, at 11:20 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 11/16/16, 11:07 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>
>> So you are suggesting to make it a top-level class. Right? Otherwise
>> we’re not good to go.
>>
>> Another problem with the definition in js.swc is that then() returns an
>> Object, while it should really return a Thenable. I don’t think Thenable
>> is defined as an interface in JS.
>
> You can use patch files and missing.js to tweak the API if you need to.
I’m a bit confused by where the types are being picked up from. js.swc
definitely gets them, and it looks like it’s getting them from es6.js. I see
that there actually is an IThenable which is a defined type, although IThenable
only has a then() method and not a catch() method.
One thing which is throwing me off is the fact that es6.as defines
Promise.resolve() like this:
/**
* @param {VALUE=} opt_value
* @return {RESULT}
* @template VALUE
* @template RESULT := type('Promise',
* cond(isUnknown(VALUE), unknown(),
* mapunion(VALUE, (V) =>
* cond(isTemplatized(V) && sub(rawTypeOf(V), 'IThenable'),
* templateTypeOf(V, 0),
* cond(sub(V, 'Thenable'),
* unknown(),
* V)))))
* =:
*/
Promise.resolve = function(opt_value) {};
I have no clue what all this template stuff means, but the js.swc is expecting
an Object as the return type.
Promise.reject() has a return type of Promise which seems more correct to me.
Is Promise.resolve() broken, and if yes, how do we fix it?
>
>>
>>> IMO, polyfills should be beads you add to your Application beads if you
>>> need them.
>>
>> Makes sense, although I’m not sure what the bead would look like.
>> I think manually adding a polyfill for I.E. in the HTML is a reasonable
>> work-around as well.
>
> The bead would use <inject_html>
>
> -Alex
>
