This brings up a related question: what is the proposed future of the builtin Reflect.parse now that we have pure-JS alternatives like Esprima?
On the 'keep' side, I've found jsreflect to be simple, well-written, and easy to maintain. Also, there seem to be a existing uses of Reflect.parse from devtools which could potentially benefit from the native performance (but I'm not sure how it is used). On the 'remove' side, Reflect.parse isn't exposed to content and I'm not aware of any specification effort being planned (it seems like the motivation would be low, given Esprima et al). Furthermore, if we have it, we shouldn't let it languish which means some amount of ongoing maintenance effort to address issues like the one below (which might not end up being too much work). Does anyone have any opinions either way? I'm mostly on the fence. Cheers, Luke ----- Original Message ----- > Hi all. > > Unfortunately, there's differences between Parser API and Esprima harmony > branch. > For example, Esprima harmony defines ArrowFunctionExpression, but Parser > API defines ArrowExpression. > This doesn't sound nice for developers using Parser API. > > Do you have any plan about this? > I think that a open process to propose a new AST node interface is needed. > This resolves differences among parsers and makes Parser API spec more > powerful. > > Thanks, > Yusuke Suzuki > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
