EcmaScript Proposal - Promised functions

[kai zhu]

> On 13 Apr 2018, at 3:48 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> 
> This seems like it could be done with decorators per https://github.com/tc39/proposal-decorators <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 <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 <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 <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"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180413/337b6fc3/attachment-0001.html>