New Promise Syntax Proposal

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

New Promise Syntax Proposal

Jorge Téllez
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
+52 1 81 2567 8257
@novohispano


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Isiah Meadows-2

I'm not convinced of the need. Promises are already sufficient, and in general use, I rarely use the constructor outside of adapting callback-related code or other lower-level cases.

Also, keep in mind, most such promise-returning functions do have arguments, which this proposal seems to miss.


On Mon, Nov 6, 2017, 10:23 Jorge Téllez <[hidden email]> wrote:
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
+52 1 81 2567 8257
@novohispano

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Oriol _
In reply to this post by Jorge Téllez

Consider using an async function:

```js
async function promiseFunction() {
  return someValue;
}
```

--Oriol

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Michael Rosefield
In reply to this post by Jorge Téllez
Adding 'promise' as a keyword when it is certainly used as a variable name throughout many codebases is asking for trouble.

I'd also add that you could use `const promiseFunction = new Promise(res, rej) { [...] }; `

As Isiah hinted, you can often be much more terse: `const promiseFunction = Promise.resolve(resValue);`

On Mon, 6 Nov 2017 at 15:23 Jorge Téllez <[hidden email]> wrote:
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
<a href="tel:+52%201%2081%202567%208257" value="+5218125678257" target="_blank">+52 1 81 2567 8257
@novohispano

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Jonathan Barronville
In reply to this post by Isiah Meadows-2
From the example provided, as someone who uses promises a lot, I’m not sure I’m sold on the need for this either. Maybe you could provide some more concrete examples, Jorge?


P.S. Proposals like this are why JavaScript should’ve been a LISP ;p …

On Mon, Nov 6, 2017 at 10:28 AM, Isiah Meadows <[hidden email]> wrote:

I'm not convinced of the need. Promises are already sufficient, and in general use, I rarely use the constructor outside of adapting callback-related code or other lower-level cases.

Also, keep in mind, most such promise-returning functions do have arguments, which this proposal seems to miss.


On Mon, Nov 6, 2017, 10:23 Jorge Téllez <[hidden email]> wrote:
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
<a href="tel:+52%201%2081%202567%208257" value="+5218125678257" target="_blank">+52 1 81 2567 8257
@novohispano

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Jonathan


Life is a game and we’re all just high density pixels.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Isiah Meadows-2
There is Sweet.js, which addresses this issue somewhat. ;-)

On Mon, Nov 6, 2017, 10:34 Jonathan Barronville <[hidden email]> wrote:
From the example provided, as someone who uses promises a lot, I’m not sure I’m sold on the need for this either. Maybe you could provide some more concrete examples, Jorge?


P.S. Proposals like this are why JavaScript should’ve been a LISP ;p …

On Mon, Nov 6, 2017 at 10:28 AM, Isiah Meadows <[hidden email]> wrote:

I'm not convinced of the need. Promises are already sufficient, and in general use, I rarely use the constructor outside of adapting callback-related code or other lower-level cases.

Also, keep in mind, most such promise-returning functions do have arguments, which this proposal seems to miss.


On Mon, Nov 6, 2017, 10:23 Jorge Téllez <[hidden email]> wrote:
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
<a href="tel:+52%201%2081%202567%208257" value="+5218125678257" target="_blank">+52 1 81 2567 8257
@novohispano

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Jonathan


Life is a game and we’re all just high density pixels.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

T.J. Crowder-2
In reply to this post by Jorge Téllez
On Mon, Nov 6, 2017 at 3:23 PM, Jorge Téllez
<[hidden email]> wrote:
>
> I would like to propose a new syntax for promises for the next ECMAScript.

We already have a concise syntax for a function that returns a promise: `async`:

```js
async function promiseFunction() {
    // Do work here, throw exception to reject,
    // perhaps use `await` to wait for other promises...
    return theResult;
};
```

More:

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Jorge Téllez
In reply to this post by Jonathan Barronville
Yes, I’ll be happy to provide a concrete example. 

Let’s say I am creating a CLI using readline.

```js
const readline  = require('readline');
const interface = readline.createInterface({
  input:  process.stdin,
  output: process.stdout
});

async function run() {
  var name = '';
  var base = 0;

  console.log('** Bienvenido al Calculador de Área **');

  name = await requestInput(‘What’s your name?\n');
  console.log(`Hello, ${name}!`);
}

function requestInput(question) {
  return new Promise(function(resolve) {
    interface.question(question, function(input) {
      resolve(input);
    })
  })
}

run();
```

Instead of defining a wrapper function that returns a promise, I would like to define the promise at the same time like this:

```js
const readline  = require('readline');
const interface = readline.createInterface({
  input:  process.stdin,
  output: process.stdout
});

async function run() {
  console.log('** Bienvenido al Calculador de Área **');

  const name = await requestInput(‘What’s your name?\n');
  console.log(`Hello, ${name}!`);
}

promise requestInput(resolve, reject, question) {
  interface.question(question, function(input) {
    resolve(input);
  })
}

run();
```
__
Jorge Téllez
+52 1 81 2567 8257
@novohispano

On Nov 6, 2017, at 9:33 AM, Jonathan Barronville <[hidden email]> wrote:

From the example provided, as someone who uses promises a lot, I’m not sure I’m sold on the need for this either. Maybe you could provide some more concrete examples, Jorge?


P.S. Proposals like this are why JavaScript should’ve been a LISP ;p …

On Mon, Nov 6, 2017 at 10:28 AM, Isiah Meadows <[hidden email]> wrote:

I'm not convinced of the need. Promises are already sufficient, and in general use, I rarely use the constructor outside of adapting callback-related code or other lower-level cases.

Also, keep in mind, most such promise-returning functions do have arguments, which this proposal seems to miss.


On Mon, Nov 6, 2017, 10:23 Jorge Téllez <[hidden email]> wrote:
I would like to propose a new syntax for promises for the next ECMAScript.

It is common to define promises in the following way:

function promiseFunction() {
  return new Promise(resolve, reject) {
    resolve(someValue);
  };
}

In the previous example, I am declaring a function so that I can access the promise throughout. 

I would like propose a simpler syntax to remove this redundancy:

promise promiseFunction(resolve, reject) {
  resolve(someValue);
}

This will make the promise declaration easier to read in a similar fashion as the new class syntax made it easier to declare prototypes.

__
Jorge Téllez
<a href="tel:+52%201%2081%202567%208257" value="+5218125678257" target="_blank" class="">+52 1 81 2567 8257
@novohispano

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Jonathan


Life is a game and we’re all just high density pixels.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

T.J. Crowder-2
On Mon, Nov 6, 2017 at 3:39 PM, Jorge Téllez
<[hidden email]> wrote:
> Yes, I’ll be happy to provide a concrete example. 

Very useful example!

In that scenario I'd convert to promises *early*, by promisifying the `interface.question` function once (using [`util.promisify`][1] or roll-your-own if needed), and then using the promisified version throughout (which lets you use `async` functions).

-- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Jonathan Barronville
@T.J. Crowder: Interestingly, in this case, it looks like the
`readline` module’s [`@question(…)`
API](https://nodejs.org/docs/v9.0.0/api/readline.html#readline_rl_question_query_callback)
doesn’t even use the usual Node.js-style callback, which is what
[`util.promisify`](https://nodejs.org/docs/v9.0.0/api/util.html#util_util_promisify_original)
expects …

On Mon, Nov 6, 2017 at 10:43 AM, T.J. Crowder
<[hidden email]> wrote:

> On Mon, Nov 6, 2017 at 3:39 PM, Jorge Téllez
> <[hidden email]> wrote:
>> Yes, I’ll be happy to provide a concrete example.
>
> Very useful example!
>
> In that scenario I'd convert to promises *early*, by promisifying the
> `interface.question` function once (using [`util.promisify`][1] or
> roll-your-own if needed), and then using the promisified version throughout
> (which lets you use `async` functions).
>
> -- T.J. Crowder
>
> [1]: https://nodejs.org/api/util.html#util_util_promisify_original



--
- Jonathan



Life is a game and we’re all just high density pixels.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: New Promise Syntax Proposal

bread
In reply to this post by Jorge Téllez
I proposed an enhanced definition for `async return` and `async throw` to
address this issue
in https://github.com/tc39/ecmascript-asyncawait/issues/38 – it didn’t get
accepted, however it is implemented in rodent
(see https://github.com/MatAtBread/nodent#exiting-async-functions-from-callbacks)


Using it would produce an async function like:

```javascript


async function requestInput(question) {
    interface.question(question, function(input) {
        async return input ;
    });
}

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

T.J. Crowder-2
In reply to this post by Jonathan Barronville
On Mon, Nov 6, 2017 at 3:57 PM, Jonathan Barronville
>
> @T.J. Crowder: Interestingly, in this case, it looks like the
> `readline` module’s `@question(…)`
> API doesn’t even use the usual Node.js-style callback,
> which is what `util.promisify` expects …

Yeah, that's why I included the "or roll-your-own if needed" bit. :-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Isiah Meadows-2
In reply to this post by Jonathan Barronville
You may find it interesting that Node.js created a private symbol to allow that and others (like `fs.exists`) to be promisified similarly, even though they don't follow the standard convention.

On Mon, Nov 6, 2017, 10:57 Jonathan Barronville <[hidden email]> wrote:
@T.J. Crowder: Interestingly, in this case, it looks like the
`readline` module’s [`@question(…)`
API](https://nodejs.org/docs/v9.0.0/api/readline.html#readline_rl_question_query_callback)
doesn’t even use the usual Node.js-style callback, which is what
[`util.promisify`](https://nodejs.org/docs/v9.0.0/api/util.html#util_util_promisify_original)
expects …

On Mon, Nov 6, 2017 at 10:43 AM, T.J. Crowder
<[hidden email]> wrote:
> On Mon, Nov 6, 2017 at 3:39 PM, Jorge Téllez
> <[hidden email]> wrote:
>> Yes, I’ll be happy to provide a concrete example.
>
> Very useful example!
>
> In that scenario I'd convert to promises *early*, by promisifying the
> `interface.question` function once (using [`util.promisify`][1] or
> roll-your-own if needed), and then using the promisified version throughout
> (which lets you use `async` functions).
>
> -- T.J. Crowder
>
> [1]: https://nodejs.org/api/util.html#util_util_promisify_original



--
- Jonathan



Life is a game and we’re all just high density pixels.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Augusto Moura
In reply to this post by Jorge Téllez
Using arrow functions it doesn't seems so verbose
```js
function requestInput(question) {
  return new Promise(function(resolve) {
    interface.question(question, function(input) {
      resolve(input);
    })
  })
}
```
can be written as:
```js
const requestInput = question => new Promise((resolve) => {
  interface.question(question, resolve); // You can wrap resolve in a `unary` helper if more than 1 argument is problematic
});
```

I don't see a problem with verbosity 
--
Augusto Moura

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New Promise Syntax Proposal

Pranay Prakash
Lot of good ideas mentioned in this thread, and I think in general, the async/await pattern helps to make code like this more terse.

Rather than inventing new syntax like:

```
promise promiseFunction(resolve, reject, …args) {
  // call to reject() or resolve()
}


the existing way of implementing this is:

```
async function promiseFunction(…args) {
  // return something (to resolve) or throw an error (to reject)
}

We already have the latter, and it is cleaner IMO

Cheers,
Pranay



On Mon, Nov 6, 2017 1:05 PM, Augusto Moura [hidden email] wrote:
Using arrow functions it doesn't seems so verbose
```js
function requestInput(question) {
  return new Promise(function(resolve) {
    interface.question(question, function(input) {
      resolve(input);
    })
  })
}
```
can be written as:
```js
const requestInput = question => new Promise((resolve) => {
  interface.question(question, resolve); // You can wrap resolve in a `unary` helper if more than 1 argument is problematic
});
```

I don't see a problem with verbosity 
--
Augusto Moura

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss