Symbol.await proposal

Wesley Oliver wesley.olis at gmail.com
Mon Jun 22 20:36:52 UTC 2020


> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have less guarantees of the binding.
> Just have to assume that every function has like a callback by convention,
> if it doesn't then break things again.
> Typescript does help.
>
> function anyArguments(callback) {
>  let args = [...arguments];
> // args.length > 99 and callback is the 1st parameters.
> }
>
> You can check out this is want project setup, that allow us to peace meal
> upgrade to ts.
> https://github.com/wesleyolis/configFactoryLoaderAndValidator
> Few additional pointers:
> type AnyJS = any; / this allow you keep track of intentional usage, so
> search codebase later.
>  If you have old library with no types, then basically import the new
> library with types under a different alias name,
> then have both old and new versions and peace meal upgrade as required.
>
> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Mon, Jun 22, 2020 at 10:13 PM Jamie <me at thejameskyle.com> wrote:
>
>> One of the common refactorings I do is:
>>
>> let file1 = await readFile(filename1)
>> let file2 = await readFile(filename2)
>> // to
>> let [file1, file2] = await Promise.all([
>>   readFile(filename1),
>>   readFile(filename2),
>> ])
>>
>> I would be very confused if refactoring it in this way made my code break
>> because of some implicit behavior around `await` specifically.
>>
>> I have seen some APIs that switch to promises when a callback argument is
>> not provided. Is this not a sufficient solution?
>>
>> On Mon, Jun 22, 2020 at 12:22 PM James M Snell <jasnell at gmail.com> wrote:
>>
>>> For many legacy code bases that are based on callbacks mechanisms like
>>> node.js' promisify function are required to help facilitate the transition
>>> from callback centric code to Promise-centric. A lot of the time, these can
>>> follow straightforward rules without requiring customization. However, at
>>> other times it is necessary for user code to provide custom implementations
>>> of the Promise-version of the function.
>>>
>>> In Node.js, we accomplish this by allowing a function to have a symbol
>>> attached whose value is an alternative function that is returned by the
>>> promisify function
>>>
>>> For instance,
>>>
>>>   function myFunction(foo, bar, callback) {
>>>     callback(null, foo, bar);
>>>   }
>>>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>>>     return [foo, bar];
>>>   }
>>>
>>>   const { promisify } = require('util');
>>>   const mine = promisify(myFunction);
>>>   (async () => console.log(await mine('a','b')))();
>>>
>>> As a convenience built into the language, it would be nice to be able to
>>> short-circuit the need to call promisify with a special language-level
>>> Symbol used specifically for this purpose:
>>>
>>>   function myFunction(foo, bar, callback) {
>>>     callback(null, foo, bar);
>>>   }
>>>   myFunction[Symbol.await] = async function(foo, bar) {
>>>     return [foo, bar];
>>>   }
>>>
>>>   (async () => console.log(await myFunction('a','b')))();
>>>
>>> The idea here is that if the function being awaited has the
>>> [Symbol.await] property whose value is a function, then that function is
>>> called when the await keyword is used. That is,
>>>
>>>   myFunction('a', 'b', callback); // Invokes myFunction directly
>>>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>>>
>>> if the Symbol.await property is not set or is not callable, then it
>>> would fallback to default behavior.
>>>
>>> Automatic handling of this binding should also happen but has some
>>> technical detail to work out:
>>>
>>>   const obj = {
>>>     a: 1,
>>>     foo() {}
>>>   };
>>>   obj.foo[Symbol.await] = async function() {
>>>     return this.a;
>>>   }
>>>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>>>
>>> This approach would make it far easier for legacy code bases to make the
>>> transition to async/await syntax while maintaining legacy compat.
>>>
>>> Before writing up a formal proposal, I wanted to solicit some feedback
>>> on this approach to see what folks thought.
>>>
>>> - James
>>> _______________________________________________
>>> 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
>>
>
>
> --
> ----
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.olis at gmail.com
>


-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200622/07e885e4/attachment.html>


More information about the es-discuss mailing list