Re: EcmaScript Proposal - Promised functions

[Jeremy Martin]

>
> > the problem with using decorators, object.defineproperty, and other
> meta-programming features in javascript, is that no one has carefully
> thought out how they can be easily debugged, especially in javascript’s
> quirky, non-blocking-design context.


That's a rather broad statement spanning many language features, and
further speaks to a predominately implementation-level concern (runtime
debugging tools), as opposed to explaining what about the specification
prohibits what you're looking for.

Regarding some of the existing suggestions from the group, while I'm not
especially familiar with compile-time type checkers for JavaScript, a quick
search seems to suggest that at least TypeScript supports both type-safe
decorators and type-safe higher order functions, which both seem
well-suited as userland solutions to this.

FWIW, I can appreciate the ergonomics of what you're advocating for here,
but please keep in mind that the implementation and specification barriers
for new syntax is much higher than for other enhancements to the language,
and I'd like to friendly suggest that this *may* not satisfy that
threshold. You would likely see a warmer response if you can demonstrate
some community demand and/or adoption of a babel plugin that implements
this feature (although, personally, I would suggest just rolling with a
userland approach).


On Fri, Apr 13, 2018 at 2:56 AM, kai zhu  wrote:

> On 13 Apr 2018, at 3:48 AM, Mike Samuel  wrote:
>
> This seems like it could be done with decorators per
> https://github.com/tc39/proposal-decorators without introducing a new
> keyword.
>
> @promises function sleep(...) {
>   ...
> }
>
>
> the problem with using decorators, object.defineproperty, and other
> meta-programming features in javascript, is that no one has carefully
> thought out how they can be easily debugged, especially in javascript’s
> quirky, non-blocking-design context.
>
> imagine google’s gwt, and removing most of its compile-time checks.
>  that's essentially the direction es6/es7/es8/etc seems to be headed (and
> if that’s the case, how is it better than gwt?).  is this what we want? a
> language with java's meta-programming power, but lacking most of its
> safety-features?
>
> how successful in getting shipped, do you think a java-project as
> complicated as a typical web-project would be without compile-time
> meta-programming checks?  exactly ... and this is pretty much what the
> current state of the web-industry is like :`(
>
> to illustrate with code, npm has this particular meta-programming gem [1],
> which leads to this surprising behavior (and corresponding real-world
> scenario where this was encountered [2]):
>
> ```js
> /*
>  * example1.js
>  *
>  * example usage:
>  * $ npm install npm && node example1.js
>  *
>  * example output:
>  * Error: Call npm.load(config, cb) before using this command.
>  * See the README.md or bin/npm-cli.js for example usage.
>  */
>
> /*jslint
> node: true
> */
>
> 'use strict';
> var command, npm;
> npm = require('npm');
> Object.keys(npm.commands).forEach(function (key) {
>
> // how many people would expect this to throw an error?
> command = npm.commands[key];
>
> // rather than this?
> try {
> command();
> } catch (ignore) {
> }
> });
> console.log('caught all errors');
> ```
>
>
>
> here's the fix that was applied (and corresponding real-world solution
> [3]).
> but again, why should web-developers have to second-guess that arbitrary
> property-accesses might throw errors (and waste valuable engineering-time
> constantly guarding against them)?
>
>
>
> ```js
> /*
>  * example2.js
>  *
>  * example usage:
>  * $ npm install npm && node example2.js
>  *
>  * example output:
>  * caught all errors
>  */
>
> /*jslint
> node: true
> */
>
> 'use strict';
> var command, npm, objectKeysSafe;
> npm = require('npm');
>
> objectKeysSafe = function (dict) {
> /*
>  * this function will return a list of the dict's keys,
>  * that are safely accessible
>  */
> return Object.keys(dict).filter(function (key) {
> try {
> return dict[key] || true;
> } catch (ignore) {
> }
> });
> };
>
> objectKeysSafe(npm.commands).forEach(function (key) {
>
> // how many people would expect this to throw an error?
> command = npm.commands[key];
>
> // rather than this?
> try {
> command();
> } catch (ignore) {
> }
> });
> console.log('caught all errors');
> ```
>
> [1] https://github.com/npm/npm/blob/v5.8.0/lib/npm.js#L112 - "npm/npm.js
> at v5.8.0 · npm/npm"
> [2] https://travis-ci.org/npmdoc/node-npmdoc-npm/builds/365262668#L1300 -
> "Travis CI - Test and Deploy Your Code with Confidence"
> [3] https://github.com/kaizhu256/node-apidoc-lite/
> blob/2017.4.12/lib.apidoc.js#L1019 - “node-apidoc-lite/lib.apidoc.js at
> 2017.4.12"
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/li

Re: EcmaScript Proposal - Promised functions

[kai zhu]

> On 13 Apr 2018, at 3:48 AM, Mike Samuel  wrote:
> 
> This seems like it could be done with decorators per 
> https://github.com/tc39/proposal-decorators 
>  without introducing a new 
> keyword.
> 
> @promises function sleep(...) {
>   ...
> }


the problem with using decorators, object.defineproperty, and other 
meta-programming features in javascript, is that no one has carefully thought 
out how they can be easily debugged, especially in javascript’s quirky, 
non-blocking-design context.

imagine google’s gwt, and removing most of its compile-time checks.  that's 
essentially the direction es6/es7/es8/etc seems to be headed (and if that’s the 
case, how is it better than gwt?).  is this what we want? a language with 
java's meta-programming power, but lacking most of its safety-features?

how successful in getting shipped, do you think a java-project as complicated 
as a typical web-project would be without compile-time meta-programming checks? 
 exactly ... and this is pretty much what the current state of the web-industry 
is like :`(

to illustrate with code, npm has this particular meta-programming gem [1], 
which leads to this surprising behavior (and corresponding real-world scenario 
where this was encountered [2]):

```js
/*
 * example1.js
 *
 * example usage:
 * $ npm install npm && node example1.js
 *
 * example output:
 * Error: Call npm.load(config, cb) before using this command.
 * See the README.md or bin/npm-cli.js for example usage.
 */

/*jslint
node: true
*/

'use strict';
var command, npm;
npm = require('npm');
Object.keys(npm.commands).forEach(function (key) {

// how many people would expect this to throw an error?
command = npm.commands[key];

// rather than this?
try {
command();
} catch (ignore) {
}
});
console.log('caught all errors');
```



here's the fix that was applied (and corresponding real-world solution [3]).
but again, why should web-developers have to second-guess that arbitrary 
property-accesses might throw errors (and waste valuable engineering-time 
constantly guarding against them)?



```js
/*
 * example2.js
 *
 * example usage:
 * $ npm install npm && node example2.js
 *
 * example output:
 * caught all errors
 */

/*jslint
node: true
*/

'use strict';
var command, npm, objectKeysSafe;
npm = require('npm');

objectKeysSafe = function (dict) {
/*
 * this function will return a list of the dict's keys,
 * that are safely accessible
 */
return Object.keys(dict).filter(function (key) {
try {
return dict[key] || true;
} catch (ignore) {
}
});
};

objectKeysSafe(npm.commands).forEach(function (key) {

// how many people would expect this to throw an error?
command = npm.commands[key];

// rather than this?
try {
command();
} catch (ignore) {
}
});
console.log('caught all errors');
```

[1] https://github.com/npm/npm/blob/v5.8.0/lib/npm.js#L112 
 - "npm/npm.js at 
v5.8.0 · npm/npm"
[2] https://travis-ci.org/npmdoc/node-npmdoc-npm/builds/365262668#L1300 
 - "Travis 
CI - Test and Deploy Your Code with Confidence"
[3] 
https://github.com/kaizhu256/node-apidoc-lite/blob/2017.4.12/lib.apidoc.js#L1019
 

 - “node-apidoc-lite/lib.apidoc.js at 2017.4.12"


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Isiah Meadows]

This is already basically possible in userland, so to me, syntax seems
wholly unnecessary.

(re: Augusto)

Your helper could be simplified further:

```js
function promised(fn) {
return (...args) => new Promise((resolve, reject) => {
Reflect.apply(fn, {resolve, reject}, args)
})
}
```

-

Isiah Meadows
m...@isiahmeadows.com

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


On Thu, Apr 12, 2018 at 5:02 PM, Augusto Moura
 wrote:
> Also it can be already be implemented in user land with high orders
> functions:
>
> ``` js
> const sleep = promised(function (time) {
>   window.setTimeout(() => this.resolve(), time);
> });
> ```
>
> A simple implementation of a `promised` helper
>
> ``` js
> const promised = (fn) => (...args) => {
>   let target;
>   const promise = new Promise((resolve, reject) => {
> target = { resolve, reject };
>   });
>   fn.apply(target, args);
>   return promise;
> }
> ```
>
>
> Em qui, 12 de abr de 2018 às 16:48, Mike Samuel 
> escreveu:
>>
>> This seems like it could be done with decorators per
>> https://github.com/tc39/proposal-decorators without introducing a new
>> keyword.
>>
>> @promises function sleep(...) {
>>   ...
>> }
>>
>>
>>
>> On Thu, Apr 12, 2018 at 12:07 PM, Luiz Felipe Frazão Gonçalves
>>  wrote:
>>>
>>> One new proposal for EcmaScript.
>>>
>>> Promised Functions
>>>
>>> Like async/await, the promised functions would be preceded by a keyword.
>>> In the case, promised, it would change the default behavior of the function,
>>> making it behave as a promise.
>>>
>>> I will use as an example a classic sleep function:
>>>
>>> function sleep(forHowLong) {
>>>   return new Promise((resolve, reject) => {
>>> setTimeout(function() {
>>>   resolve();
>>>
>>>   /**
>>>* For reject:
>>>*
>>>* reject(Error('Some error'));
>>>*/
>>> }, forHowLong);
>>>   });
>>> }
>>>
>>> I think to avoid the huge amount of callbacks, there should be a syntax
>>> similar to this:
>>>
>>> promised function sleep(forHowLong) {
>>>   setTimeout(function() {
>>> this.resolve(); // could even create a keyword like "resolve"
>>>
>>> /**
>>>  * For reject:
>>>  *
>>>  * this.reject(Error('Some error'));
>>>  */
>>>   }, forHowLong);
>>> }
>>>
>>> Note that the hypothetical keyword "promised" before the function
>>> statement makes it act as a promise.
>>>
>>> Just a crazy idea I had. :)
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> --
> Augusto Moura
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Augusto Moura]

Also it can be already be implemented in user land with high orders
functions:

``` js
const sleep = promised(function (time) {
  window.setTimeout(() => this.resolve(), time);
});
```

A simple implementation of a `promised` helper

``` js
const promised = (fn) => (...args) => {
  let target;
  const promise = new Promise((resolve, reject) => {
target = { resolve, reject };
  });
  fn.apply(target, args);
  return promise;
}
```


Em qui, 12 de abr de 2018 às 16:48, Mike Samuel 
escreveu:

> This seems like it could be done with decorators per
> https://github.com/tc39/proposal-decorators without introducing a new
> keyword.
>
> @promises function sleep(...) {
>   ...
> }
>
>
>
> On Thu, Apr 12, 2018 at 12:07 PM, Luiz Felipe Frazão Gonçalves <
> luizfelipefrazaogoncal...@gmail.com> wrote:
>
>> *One new proposal for EcmaScript.*
>> Promised Functions
>>
>> Like async/await, the promised functions would be preceded by a keyword.
>> In the case, promised, it would change the default behavior of the
>> function, making it behave as a promise.
>>
>> I will use as an example a classic sleep function:
>>
>> function sleep(forHowLong) {
>>   return new Promise((resolve, reject) => {
>> setTimeout(function() {
>>   resolve();
>>
>>   /**   * For reject:   ** reject(Error('Some error'));  
>>  */
>> }, forHowLong);
>>   });
>> }
>>
>> I think to avoid the huge amount of callbacks, there should be a syntax
>> similar to this:
>>
>> promised function sleep(forHowLong) {
>>   setTimeout(function() {
>> this.resolve(); // could even create a keyword like "resolve"
>>
>> /** * For reject: *  * this.reject(Error('Some error')); 
>> */
>>   }, forHowLong);
>> }
>>
>> Note that the hypothetical keyword "promised" before the function
>> statement makes it act as a promise.
>>
>> Just a crazy idea I had. :)
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Mike Samuel]

This seems like it could be done with decorators per
https://github.com/tc39/proposal-decorators without introducing a new
keyword.

@promises function sleep(...) {
  ...
}



On Thu, Apr 12, 2018 at 12:07 PM, Luiz Felipe Frazão Gonçalves <
luizfelipefrazaogoncal...@gmail.com> wrote:

> *One new proposal for EcmaScript.*
> Promised Functions
>
> Like async/await, the promised functions would be preceded by a keyword.
> In the case, promised, it would change the default behavior of the
> function, making it behave as a promise.
>
> I will use as an example a classic sleep function:
>
> function sleep(forHowLong) {
>   return new Promise((resolve, reject) => {
> setTimeout(function() {
>   resolve();
>
>   /**   * For reject:   ** reject(Error('Some error'));   
> */
> }, forHowLong);
>   });
> }
>
> I think to avoid the huge amount of callbacks, there should be a syntax
> similar to this:
>
> promised function sleep(forHowLong) {
>   setTimeout(function() {
> this.resolve(); // could even create a keyword like "resolve"
>
> /** * For reject: *  * this.reject(Error('Some error')); 
> */
>   }, forHowLong);
> }
>
> Note that the hypothetical keyword "promised" before the function
> statement makes it act as a promise.
>
> Just a crazy idea I had. :)
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Naveen Chawla]

I'd prefer a "new Promise" literal analogous to {} for objects and '' for
strings:

```js
p\
resolve=>
setTimeout(
resolve,
forHowLong)
\
```

I think the "this.resolve" proposal wouldn't work for methods, for example.

On Thu, 12 Apr 2018 at 23:25 Michał Wadas  wrote:

> Is it codyfing of glorious The Deferred anti-pattern?
> https://github.com/petkaantonov/bluebird/wiki/Promise-Anti-patterns#the-deferred-anti-pattern
>
> On Thu, Apr 12, 2018 at 6:07 PM, Luiz Felipe Frazão Gonçalves <
> luizfelipefrazaogoncal...@gmail.com> wrote:
>
>> *One new proposal for EcmaScript.*
>> Promised Functions
>>
>> Like async/await, the promised functions would be preceded by a keyword.
>> In the case, promised, it would change the default behavior of the
>> function, making it behave as a promise.
>>
>> I will use as an example a classic sleep function:
>>
>> function sleep(forHowLong) {
>>   return new Promise((resolve, reject) => {
>> setTimeout(function() {
>>   resolve();
>>
>>   /**   * For reject:   ** reject(Error('Some error'));  
>>  */
>> }, forHowLong);
>>   });
>> }
>>
>> I think to avoid the huge amount of callbacks, there should be a syntax
>> similar to this:
>>
>> promised function sleep(forHowLong) {
>>   setTimeout(function() {
>> this.resolve(); // could even create a keyword like "resolve"
>>
>> /** * For reject: *  * this.reject(Error('Some error')); 
>> */
>>   }, forHowLong);
>> }
>>
>> Note that the hypothetical keyword "promised" before the function
>> statement makes it act as a promise.
>>
>> Just a crazy idea I had. :)
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[kai zhu]

or ... you could bypass these low-level promise-abstractions altogether, and 
elegantly solve the actual integration-level task asked by your pm - with a 
single, easy-to-debug, throwaway recursive-callback (which will likely work 
exactly the same 10 years from now, while god-knows how the magic will evolve 
with promises in that time).

```javascript
/*
 * example.js
 *
 * example usage:
 * $ FOR_HOW_LONG=1000 node example.js
 *
 * example output:
 * 0 ms - start recusive-callback
 * 1005 ms - waited for server and db to initialize
 * 1007 ms - read file example.js which had 2519 characters
 * 1844 ms - fetched 1270 bytes of data from https://www.example.com
 * 1844 ms - finished recursive-callback
 */

/*jslint
bitwise: true,
browser: true,
maxerr: 4,
maxlen: 100,
node: true,
nomen: true,
regexp: true,
stupid: true
*/
'use strict';
var modeNext, onNext, timeStart, tmp;

onNext = function (error, data) {
// For reject:
if (error) {
console.error(error);
return;
}
modeNext += 1;
switch (modeNext) {
case 1:
timeStart = Date.now();
console.log((Date.now() - timeStart) + ' ms - ' +
'start recusive-callback');
// sleep
setTimeout(onNext, process.env.FOR_HOW_LONG);
break;
case 2:
console.log((Date.now() - timeStart) + ' ms - ' +
'waited for server and db to initialize');
onNext();
break;
case 3:
// read this file
require('fs').readFile(__filename, 'utf8', onNext);
break;
case 4:
console.log((Date.now() - timeStart) + ' ms - ' +
'read file ' + __filename + ' which had ' + data.length + ' 
characters');
onNext();
break;
case 5:
// fetch data from https://www.example.js
require('https').request(
require('url').parse('https://www.example.com'),
function (response) {
onNext(null, response);
}
)
// handle http-request error
.on('error', onNext)
.end();
break;
case 6:
// handle http-response error
data.on('error', onNext);
// collect http-response chunks
tmp = [];
data.on('data', function (chunk) {
tmp.push(chunk);
});
// concatenate http-response chunks
data.on('end', function () {
onNext(null, Buffer.concat(tmp));
});
break;
case 7:
console.log((Date.now() - timeStart) + ' ms - ' +
'fetched ' + data.length + ' bytes of data from 
https://www.example.com');
onNext();
break;
case 8:
console.log((Date.now() - timeStart) + ' ms - ' +
'finished recursive-callback');
break;
}
};

modeNext = 0;
onNext();
```

> On 13 Apr 2018, at 12:07 AM, Luiz Felipe Frazão Gonçalves 
>  wrote:
> 
> One new proposal for EcmaScript.
> 
> Promised Functions
> 
> Like async/await, the promised functions would be preceded by a keyword. In 
> the case, promised, it would change the default behavior of the function, 
> making it behave as a promise.
> 
> I will use as an example a classic sleep function:
> 
> function sleep(forHowLong) {
>   return new Promise((resolve, reject) => {
> setTimeout(function() {
>   resolve();
> 
>   /**
>* For reject:
>* 
>* reject(Error('Some error'));
>*/
> }, forHowLong);
>   });
> }
> I think to avoid the huge amount of callbacks, there should be a syntax 
> similar to this:
> 
> promised function sleep(forHowLong) {
>   setTimeout(function() {
> this.resolve(); // could even create a keyword like "resolve"
> 
> /**
>  * For reject:
>  * 
>  * this.reject(Error('Some error'));
>  */
>   }, forHowLong);
> }
> Note that the hypothetical keyword "promised" before the function statement 
> makes it act as a promise.
> 
> Just a crazy idea I had. :)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


> On 13 Apr 2018, at 12:19 AM, Tab Atkins Jr.  wrote:
> 
> On Thu, Apr 12, 2018 at 9:07 AM, Luiz Felipe Frazão Gonçalves
>  > wrote:
>> One new proposal for EcmaScript.
>> 
>> Promised Functions
>> 
>> Like async/await, the promised functions would be preceded by a keyword. In
>> the case, promised, it would change the default behavior of the function,
>> making it behave as a promise.
>> 
>> I will use as an example a classic sleep function:
>> 
>> function sleep(forHowLong) {
>>  return new Promise((resolve, reject) => {
>>setTimeout(function() {
>>  resolve();
>> 
>>  /**
>>   * For reject:
>>   *
>>   * reject(Error('Some error'));
>>   */
>>}, forHowLong);
>>  });
>> }
>> 
>> I think to avoid the huge amount of callbacks, there should be a sy

Re: EcmaScript Proposal - Promised functions

[Michał Wadas]

Is it codyfing of glorious The Deferred anti-pattern?
https://github.com/petkaantonov/bluebird/wiki/Promise-Anti-patterns#the-deferred-anti-pattern

On Thu, Apr 12, 2018 at 6:07 PM, Luiz Felipe Frazão Gonçalves <
luizfelipefrazaogoncal...@gmail.com> wrote:

> *One new proposal for EcmaScript.*
> Promised Functions
>
> Like async/await, the promised functions would be preceded by a keyword.
> In the case, promised, it would change the default behavior of the
> function, making it behave as a promise.
>
> I will use as an example a classic sleep function:
>
> function sleep(forHowLong) {
>   return new Promise((resolve, reject) => {
> setTimeout(function() {
>   resolve();
>
>   /**   * For reject:   ** reject(Error('Some error'));   
> */
> }, forHowLong);
>   });
> }
>
> I think to avoid the huge amount of callbacks, there should be a syntax
> similar to this:
>
> promised function sleep(forHowLong) {
>   setTimeout(function() {
> this.resolve(); // could even create a keyword like "resolve"
>
> /** * For reject: *  * this.reject(Error('Some error')); 
> */
>   }, forHowLong);
> }
>
> Note that the hypothetical keyword "promised" before the function
> statement makes it act as a promise.
>
> Just a crazy idea I had. :)
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Tab Atkins Jr.]

On Thu, Apr 12, 2018 at 9:07 AM, Luiz Felipe Frazão Gonçalves
 wrote:
> One new proposal for EcmaScript.
>
> Promised Functions
>
> Like async/await, the promised functions would be preceded by a keyword. In
> the case, promised, it would change the default behavior of the function,
> making it behave as a promise.
>
> I will use as an example a classic sleep function:
>
> function sleep(forHowLong) {
>   return new Promise((resolve, reject) => {
> setTimeout(function() {
>   resolve();
>
>   /**
>* For reject:
>*
>* reject(Error('Some error'));
>*/
> }, forHowLong);
>   });
> }
>
> I think to avoid the huge amount of callbacks, there should be a syntax
> similar to this:

Some of these callbacks aren't necessary:

function sleep(forHowLong) {
  return new Promise(resolve=>setTimeout(resolve, forHowLong));
}

Tho even if you do use all the same callbacks, just formatting it
properly helps:

function sleep(forHowLong) {
  return new Promise(resolve=>setTimeout(_=>resolve(), forHowLong));
}

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal - Promised functions

[Sebastian Malton]

  Interesting idea, though I feel that this is too similar to async functions. What would be useful would some standard way of "awaiting" functions that require callbacks. Sort of like bluebird's Promise.fromCallback. Maybe ```jsawait.fromCallback fn()```Which can only be used by a function call and the postpends the parameters with a suitable callback function Sebastian MaltonFrom: luizfelipefrazaogoncal...@gmail.comSent: April 12, 2018 12:07 PMTo: es-discuss@mozilla.orgSubject: EcmaScript Proposal - Promised functions  

One new proposal for EcmaScript.Promised FunctionsLike async/await, the promised functions would be preceded by a keyword. In the case, promised, it would change the default behavior of the function, making it behave as a promise.I will use as an example a classic sleep function:function sleep(forHowLong) {
  return new Promise((resolve, reject) => {
setTimeout(function() {
  resolve();

  /**
   * For reject:
   * 
   * reject(Error('Some error'));
   */
}, forHowLong);
  });
}I think to avoid the huge amount of callbacks, there should be a syntax similar to this:promised function sleep(forHowLong) {
  setTimeout(function() {
this.resolve(); // could even create a keyword like "resolve"

/**
 * For reject:
 * 
  * this.reject(Error('Some error'));
 */
  }, forHowLong);
}Note that the hypothetical keyword "promised" before the function statement makes it act as a promise.Just a crazy idea I had. :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

EcmaScript Proposal - Promised functions

[Luiz Felipe Frazão Gonçalves]

*One new proposal for EcmaScript.*
Promised Functions

Like async/await, the promised functions would be preceded by a keyword. In
the case, promised, it would change the default behavior of the function,
making it behave as a promise.

I will use as an example a classic sleep function:

function sleep(forHowLong) {
  return new Promise((resolve, reject) => {
setTimeout(function() {
  resolve();

  /**   * For reject:   ** reject(Error('Some
error'));   */
}, forHowLong);
  });
}

I think to avoid the huge amount of callbacks, there should be a syntax
similar to this:

promised function sleep(forHowLong) {
  setTimeout(function() {
this.resolve(); // could even create a keyword like "resolve"

/** * For reject: *  * this.reject(Error('Some error')); */
  }, forHowLong);
}

Note that the hypothetical keyword "promised" before the function statement
makes it act as a promise.

Just a crazy idea I had. :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss