[strawman] Symbol.thenable proposal

[doodad-js Admin]

I mean you could have an interface IThenable that you implement to a class/constructor. Then each instantiated object of such class/constructor can be "identified" as a Thenable. Yes, that involves a type system.

-----Original Message-----
From: impinball at gmail.com <impinball at gmail.com> On Behalf Of Isiah Meadows
Sent: Sunday, April 15, 2018 6:06 PM
To: Claude Petit <petc at webmail.us>
Cc: Jordan Harband <ljharb at gmail.com>; es-discuss <es-discuss at mozilla.org>
Subject: Re: [strawman] Symbol.thenable proposal

Not sure how this is relevant, since this is about types rather than identity, and I'd say typing values is *far* from a solved problem beyond the basic concept of "all values have a type"...\* ;-)

\* https://en.wikipedia.org/wiki/Type_system

-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Apr 14, 2018 at 5:59 PM, Claude Petit <petc at webmail.us> wrote:
> I don't want to be annoying, but object identity is something solved since a long long time by classical OOP   ¯\_(ツ)_/ ¯   But I might by "wrong" as usual...
>
> -----Original Message-----
> From: Isiah Meadows <isiahmeadows at gmail.com>
> Sent: Friday, April 13, 2018 9:01 PM
> To: Jordan Harband <ljharb at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Subject: Re: [strawman] Symbol.thenable proposal
>
> I can't remember where, but I recall seeing this discussed elsewhere 
> (maybe in the TC39 meeting notes?) and the conclusion was basically
> ¯\_(ツ)_/¯. I'm not convinced myself it's actually worth the extra 
> symbol just to make something not considered a thenable - all these 
> Promise libraries have been able to get away with it for this long; 
> what makes ES promises any different here? (Dynamic import is probably 
> the only possible case I can think of short certain proxies in terms 
> of things that could be considered thenables but shouldn't always.)
>
> Worst case, you can just return a value that happens to have a promise in a property, like in `{value: somePromise}` - nobody resolves that except `co` IIRC.
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Fri, Apr 13, 2018 at 4:20 PM, Jordan Harband <ljharb at gmail.com> wrote:
>> `await import(path)` wouldn't ever be able to do anything besides 
>> Promise.resolve; I'm pretty confident that this proposal, or 
>> something like it, is the only possibility to make ModuleRecords (for 
>> modules that export a `then` function) not be considered thenable.
>>
>> On Fri, Apr 13, 2018 at 8:02 AM, Guy Bedford <guybedford at gmail.com> wrote:
>>>
>>> It's worth noting that the driving use case here is coming from 
>>> NodeJS development hitting issues where the guaranteed result for 
>>> dynamic import resolution can't be assumed to be a module namespace, 
>>> although please correct me if I'm wrong here Gus.
>>>
>>> Alternatively could this mitigation be handled by creating a 
>>> `Promise.resolveStrict` primitive that explicitly opts-out of 
>>> thenable resolution in the promise chain?
>>>
>>> I'd think we are getting further and further away now from 
>>> third-party promise implementation interops, that such approaches 
>>> might make sense to consider at this point, in the name of returning 
>>> to more well-defined semantics.
>>>
>>> On Fri, Apr 13, 2018 at 3:33 AM Gus Caplan <me at gus.host> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> In an effort to curtail the interesting behavior of Promise.resolve 
>>>> (especially with regard to dynamic import), I have created a 
>>>> proposal for a well-known symbol which will allow an object to not 
>>>> be treated as a "thenable."
>>>>
>>>> I am privy to the current protocol proposal which might be a better 
>>>> fit for this, but due to dynamic import already being stage 3, I 
>>>> don't feel we should wait for it to come to fruition.
>>>>
>>>> Comments and suggestions are of course quite welcome at the repo [1].
>>>>
>>>> Thanks,
>>>> -Gus
>>>>
>>>> [1]: https://github.com/devsnek/proposal-symbol-thenable
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>