Hi!
First, experiences of this guy
https://medium.com/@bluepnume/intentionally-unleashing-zalgo-with-promises-ab3f63ead2fd
seem to refute the problematicity of zalgo.
Second, I actually have the use case of this pattern (though actually
it's not a use case for a new syntax). In Amber Smalltalk
(implementation running of top of JS engine), it would immensely help to
be able to have classical "proxied message send" case, where message
send is asynchronous in the background. As Amber compiles the code
itself, you may say "compile it so you simply await every message send",
but then, code that _must be_ synchronous (callbacks used in external JS
libs API) will fail. Having two modes is not an option. So I would
really use the option to have message sends synchronous by default, but
in the case they _can be_ asynchronous, to be able to let them be that way.
Actually, the paypal guy mentioned in the first paragraph has similar
case (inter-frame RPC). Using his ZalgoPromise I could compile the
things like
ZalgoPromise.resolve(make the message send).then(function (result) ...
Herby
On 8. 10. 2019 22:25, Tab Atkins Jr. wrote:
I'm not sure I understand the intended use-case here. If the author
knows the function they're calling is async, they can use `await`
normally. If they know it's not async, they can avoid `await`
altogether. If they have no idea whether it's async or not, that means
they just don't understand what the function is returning, which
sounds like a really bad thing that they should fix? And in that
case, as Gus says, `await?`'s semantics would do some confusing things
to execution order, making the line after the `await?` either run
*before* or *after* the calling code, depending on whether the await'd
value was a promise or not.
~TJ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
