François REMY wrote:
My point is: how do you make sure you don't redefine an existing
syntax? Or, if that the syntax you're defining for your personnal use
will not be reclaimed by a next version of ES?
// Polyfill for syntaxFeature:
/*@cc_on
/*@if !support syntaxFeature */
code that emulate the syntaxFeature
/* @endif */
*/
There's probably an anwser to that question, it's just that I'm not
aware of it already :-)
Yes, polyfilling means has-syntax testing. I'm told the sweet.js project
is considering how to do this, but I bet a donut that it'll not look
like CPP or @-CPP or any such ugly blast from the past.
More in a bit.
/be
-----Message d'origine----- From: Brendan Eich
Sent: Tuesday, September 18, 2012 7:17 PM
To: François REMY
Cc: Luke Hoban ; Andreas Rossberg ; Paul Leathers ;
[email protected]
Subject: Re: JS syntax future-proofing, Macros, the "Reader" (was:
Performance concern with let/const)
François REMY wrote:
| But if we have macros, then many progressive
| enhancement and anti-regressive polyfill approaches can be done, even
| with new syntax (not just with APIs).
Seems like another good way of fixing the issue :-) However, this
seems to require some form of conditionnal compilation to work ,
right? [1]
[1] http://www.javascriptkit.com/javatutors/conditionalcompile.shtml
Macros have nothing to do with conditional compilation _per se_. When
you read Macros in a JS context, don't think the C Pre-Processor, think
Scheme!
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
