On May 18, 2011, at 6:46 AM, Sam Tobin-Hochstadt wrote: > On Wed, May 18, 2011 at 2:59 AM, Luke Hoban <[email protected]> wrote: >>>> That sort of pattern certainly can be repeated if push comes to shove. >>>> But I believe doing so is far inferior to dedicated, first-class >>>> syntactical support to make the semantics absolutely unambiguous and >>>> un-confusable with anything else. >> >> This makes sense. I just want to make sure that the fundamental capability >> to subclass built-in objects is available via libraries for text/javascript, >> with the new syntax offering the more performant option for text/harmony. > > Perhaps I'm missing something, but <| seems like something that could > be provided to 'text/javascript' just as easily as > 'text/the-next-javascript'. Unlike using |module| as a keyword, or > changing the scope rules or |typeof null|, no working > 'text/javascript' program uses <| at the moment.
Couple of small points, one I already laid on Luke in a private reply: 1. text/javascript is unregistered HTML4 noise. RFC4329 has application/javascript and application/ecmascript with version parameter reserved. 2. Developers want new syntax not to choke old browsers. I've been there in 1996-2001 with ES2 and ES3. So using a new type or version value hides the new syntax from old browsers. You have to do something for the old browsers, of course, either server-side or client-side. See http://wiki.ecmascript.org/doku.php?id=strawman:versioning and its links. I'm going to improve this page shortly. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
