> > > 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 <kaizhu...@gmail.com> wrote: > On 13 Apr 2018, at 3:48 AM, Mike Samuel <mikesam...@gmail.com> 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 > > -- Jeremy Martin 661.312.3853 @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
