Closed zloirock closed 5 years ago
I think we should think about transpilation, rather than polyfilling for built-in decorators. Things that are be done with ordinary decorators can be polyfilled. We can implement the built-in decorator syntax in Babel and let transforms do the work.
Maybe the name "built-in decorator" is confusing. Polyfilling a built-in decorator should be thought of as like polyfilling async
--it just doesn't make sense.
So, in this case, if it's just a way for adding an unlimited number of new keywords, "built-in" here confuses, because, seems, in the future, after shipping decorators proposal, usual decorators for some popular cases can be added to the standard library and in this case, they can be called built-in decorators too.
Yeah, do you have any other ideas for the name?
I don't know. Maybe pseudo-decorators? Because some proposed features like @[resource] { /* block */ }
definitely are not decorators. Need to think about options.
maybe just “at-syntax” - that way, decorators are just one (unbracketed) form of at-syntax?
(FWIW the initial name I had was "generalized pseudo-decorators", but I thought that was too obscure.)
The word “pragma” is used several times in the readme. It seems both accurate and familiar, and it isn’t used presently in the ES spec to refer to anything else ('use strict' being a 'directive').
Seems it can be closed.
We can polyfill built-ins, what about built-in decorators?
Sure, some use cases of built-in decorators from this proposal can't be polyfilled. But some cases which could work as usual decorators like autobind can. New built-in decorators can be added in the future. Polyfilled built-in decorators can be used with transpilers in actual engines with transpilers. So if it's a proposal for built-ins, but not a way to add an unlimited number of new keywords, this proposal should contain a way for polyfilling at least for non-magic decorators.