The 1JS experiment has failed. Let's return to plan A.

classic Classic list List threaded Threaded
180 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

The 1JS experiment has failed. Let's return to plan A.

Mark S. Miller-2
Hi Brian, thanks for accumulating this data!

Between
* this data,
* Apple's decision as recorded at
<https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
* the new function syntax micro-modes,
* and the "let" issues already discussed,
I reiterate that we should stop trying to twist the language to
somehow shoehorn ES6 features into non-strict mode.

For both "function" and "let", when we first discussed trying to
retrofit sense into ES6 non-strict mode, we knew that this was
speculative, because non-strict mode cannot include web-breaking
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including "let" and nested "function", should be
available only in strict mode. For new function syntax, if
shoe-horning it into non-strict mode requires micro-modes as
previously discussed, then we shouldn't. Whatever the complaints about
living with one mode distinction, we're certainly not addressing these
complaints by introducing more mode distinctions.



On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
<[hidden email]> wrote:

> I have some data on patterns and sites that may break due to the proposed
> change to semantics of function decls in block scope. I am not advocating
> for any changes here but merely dumping some data I’ve gathered. I will
> continue gathering data about this breaking change and potentially others
> (eg. let[x] = 1), so any further data you folks are interested in let me
> know. I think the January meeting would be a good venue to discuss any of
> this in detail if warranted.
>
> On December 17th, 2235 sites were crawled and their scripts downloaded.
> These scripts were then processed in an attempt to identify likely breakages
> due to the change to the semantics of func decls in block scope. In this
> dataset, 4% of the scripts contained a function declaration in block scope
> (mostly inside if and try, although pretty much every node contains a
> function somewhere in this dataset). However, most of these scripts use the
> function within the same block and so won’t be broken. 20 sites, however,
> will likely be broken by this change in some way. There is also a chance
> that the tool used to identify breakages has missed some code that will
> breka.
>
>
>
> Below are some examples of code on the web today that will be broken. For
> each I include a snippet of code that is heavily edited in an attempt to
> convey the pattern used and the developer intent. I also attempt to identify
> what functionality will actually be broken.
>
>
>
> Most of the breakages occur in non-library code, with two exceptions: qTip
> 1.0, and thickbox 3.
>
>
>
> # http://ninemsn.com.au
>
>
>
> RenderModal = function () {
>
>     if (x) { // is an array of shortcuts that can be added. Is statically
> non-empty.
>
>         function K() {
>
>             // process the array of shortcuts in some way
>
>         }
>
>     }
>
>     K();
>
> };
>
>
>
> ## Scenario
>
>
>
> 1.       Navigate to main page.
>
> 2.       Click “Add other shortcuts”
>
> 3.       Click “View more shortcuts” – this will not work.
>
>
>
>
>
> # http://yandex.ru
>
>
>
> if (_ycssjs("BaH0Fmmo2Sg24lRmTPrK0B8qpaA")) {
>
>     function cp(g, c, d) { /* ...*/ }
>
>
>
>     function csh_ifgsid(c, b) { /*...*/ } }
>
>
>
> // ... thousands of lines of code ...
>
>
>
>
>
> if (_ycssjs("rO+QIoSf2L0NwDn6vjJjy+27nxI")) {
>
>     function news() {
>
>         csh_if_gsid();
>
>     }
>
> }
>
>
>
> if (_ycssjs("YRPF0QVjJmhRiKRu6cvi3YXqYo8")) {
>
>     // ... bunch of stuff ...
>
>     cp();
>
> }
>
>
>
> ## Scenario
>
>
>
> Unknown
>
>
>
>
>
> # http://g.espncdn.com/nfl-primetime-payoff/en/module/entry?matchupid=478
>
>
>
> if (isIE && isWin) {
>
>     // ...
>
> } else {
>
>     function JSGetSwfVer(i){
>
>         // ...
>
>     }
>
> }
>
>
>
> function checkFlash(myRev) {
>
>     // ...
>
>
>
>     if (isIE && isWin) {
>
>         // ...
>
>     } else {
>
>         aV = JSGetSwfVer(rV);
>
>     }
>
>
>
> }
>
>
>
> ## Scenario
>
>
>
> Can’t find a page which uses this code.
>
>
>
>
>
> # http://www.t-online.de
>
>
>
> if (!Adition_Environment) {
>
>     var Adition_Environment = (function () {
>
>         var _this = {};
>
>         // ...
>
>         _this.getPrf = function (cuId) {
>
>             var prf = "";
>
>             try {
>
>                 prf = Adition_Prfstr(cuId);
>
>             } catch (e) { }
>
>             return prf;
>
>         };
>
>         // ...
>
>     })();
>
> }
>
>
>
> // snip 1k lines
>
> if (typeof Adition_Prfstr == "undefined") {
>
>     function Adition_Prfstr(ADITION_CONTENTUNIT_ID) {
>
>         // ...
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Required to display advertisements on the page.
>
>
>
>
>
>
>
> # http://manormystery.com
>
>
>
> if (!window._ate) {
>
>     window._ate = { /* ... */ };
>
>     function addthis_open() { /* ... */ } } else { _ate.inst++; }
>
>
>
> if (_atc.abf) {
>
>     addthis_open(document.getElementById("ab"), "emailab",
> window.addthis_url || "[URL]", window.addthis_title || "[TITLE]"); }
>
>
>
> ## Scenario
>
>
>
> Social sharing popups broken at least. This may be a general utility used in
> a number of places.
>
>
>
>
>
>
>
> # http://manhunt.net (NSFW, DO NOT VISIT AT WORK)
>
>
>
> /** @todo isFlashInstalled() should probably be gotten by include from
> js/cmmn/flashDetect.js or upfunc.js. */
>
>
>
> if (typeof isFlashInstalled == 'undefined') {
>
>     function isFlashInstalled() {
>
>         var requiredMajorVersion = 6; // Major version of Flash required
>
>         var requiredMinorVersion = 0;   // Minor version of Flash required
>
>         var requiredRevision = 0;   // Minor version of Flash required
>
>         var s = new SWFObject();
>
>         if (!s) return false;
>
>         var version = s.installedVer;
>
>         if (!version) return false;
>
>         return (version.major >= requiredMajorVersion && version.minor >=
> requiredMinorVersion && version.rev >= requiredRevision);
>
>     }
>
> }
>
> isFlashInstalled();
>
>
>
> ## Scenario
>
>
>
> I avoided this site at work for obvious reasons, but it looks like all login
> functionality will be broken.
>
>
>
>
>
>
>
>
>
> # http://www.163.com
>
>
>
> NTESAD_Couplet.prototype = {
>
>     NTESCreate: function () {
>
>
>
>         var widthsmall = this.options.widthsmall;
>
>         var width = this.options.width;
>
>
>
>         if (this.options.leftbig != "" && this.options.leftsmall != "") {
>
>             function bighide() {
>
>                 coupletLeft.style.display = "none";
>
>                 coupletLeftsmall.style.display = "block";
>
>             }
>
>
>
>             function smallhide() {
>
>                 coupletLeftsmall.style.display = "none";
>
>                 coupletLeft.style.display = "block";
>
>             }
>
>         }
>
>
>
>         if (this.options.rightbig != "" && this.options.rightsmall != "") {
>
>             function Rbighide() {
>
>                 coupletRight.style.display = "none";
>
>                 coupletRightsmall.style.display = "block";
>
>             }
>
>         }
>
>
>
>         if (this.NTESPosition()) {
>
>             if (this.options.leftbig != "" && this.options.leftsmall != ""
> && this.options.rightbig != "" && this.options.rightsmall != "") {
>
>                 this.NTESBind(coupletclose, "click", function () {
> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
> coupletLeftsmall.style.display = "none"; });
>
>                 this.NTESBind(coupletclose2, "click", function () {
> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
> coupletLeftsmall.style.display = "none"; });
>
>             }
>
>         }
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Unknown.
>
>
>
>
>
>
>
> # http://www22.verizon.com
>
>
>
> if (floatStyle.match(/Content/)) {
>
>     var contentDiv = d.getElementById(_b.Preferences.Render.main_content_id
> || "content");
>
>     if (contentDiv == null) {
>
>         floatStyle = this.Preferences.Render.float_style = 'fixed'
>
>     }
>
>     function getRightOfContent() {
>
>         return contentDiv.offsetWidth + contentDiv.offsetLeft + 1
>
>     }
>
>     function fixBackground() {
>
>         if (_b.Preferences.Render.fix_background) {
>
>             db.style.backgroundAttachment = "scroll";
>
>             var margin = null;
>
>             if (document.defaultView &&
> document.defaultView.getComputedStyle) {
>
>                 margin =
> parseInt(document.defaultView.getComputedStyle(contentDiv,
> null).getPropertyValue("margin-left"), 10)
>
>             } else {
>
>                 margin = parseInt(contentDiv.currentStyle.marginLeft, 10)
>
>             }
>
>             if (isNaN(margin) || margin == 0) {
>
>                 margin = contentDiv.offsetLeft || 0
>
>             }
>
>             db.style.backgroundPosition = (Math.floor(contentDiv.scrollWidth
> * -0.5) - 2 + margin) + 'px 0'
>
>         }
>
>     }
>
> }
>
>
>
> // getRightOfContent/fixBackground used repeatedly after this.
>
>
>
> ## Scenario
>
>
>
> Couldn’t find a scenario where this code was hit, but the site is expansive.
> Also, the above code is found in at least 2 different scripts across the
> site.
>
>
>
>
>
>
>
>
>
> # http://www.jeuxvideo.com
>
>
>
> if (typeof getAppNexusMegaTag == 'undefined' || typeof getAppNexusMegaTag !=
> 'function') {
>
>     function getSize1080667() {
>
>         return '250x250';
>
>     }
>
> }
>
>
>
> if (typeof inFIF != "undefined" && inFIF == true) {
>
>     try {
>
>         parent.getSize1080667 = getSize1080667;
>
>     } catch (e) { }
>
> }
>
>
>
>
>
> ## Scenario
>
> Ad won’t display.
>
>
>
>
>
>
>
> # http://msn.foxsports.com
>
> /* this function is much faster, so if possible we use it. Some IEs are the
> only ones I know of that need the idiotic second function, generated by an
> if clause.  */ function add32(a, b) {
>
>     return (a + b) & 0xFFFFFFFF;
>
> }
>
>
>
> if (md5('hello') != '5d41402abc4b2a76b9719d911017c592') {
>
>     function add32(x, y) {
>
>         var lsw = (x & 0xFFFF) + (y & 0xFFFF),
>
>             msw = (x >> 16) + (y >> 16) + (lsw >> 16);
>
>         return (msw << 16) | (lsw & 0xFFFF);
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Nothing is necessary broken about this, as long as the first add32 functions
> properly (today everyone with this code is using the second function). This
> is a fairly common MD5 library (do a search for “idiotic second function” to
> get an idea, however this was only found once in the dataset).
>
>
>
>
>
>
>
>
>
>
>
> # http://iwiw.hu/i/belepes
>
>
>
> (function () {
>
>     if (jQuery.fn.lazyload) {
>
>         function a() {
>
>             return typeof f !== "undefined" ? f : (f =
> jQuery("body").hasClass("lazyloadimages"))
>
>         }
>
>     }
>
>     jQuery(function () {
>
>         if (a()) {
>
>             d.apply(document.body)
>
>         }
>
>     })
>
> })();
>
>
>
> ## Scenario
>
>
>
> Unknown
>
>
>
>
>
>
>
>
>
> # http://www.laposte.net
>
>
>
> if (!window.$extend) {
>
>     function $extend(c, a) {
>
>         for (var b in (a || {})) {
>
>             c[b] = a[b]
>
>         } return c
>
>     }
>
> }
>
> // $extend used repeatedly after this
>
>
>
> ## Scenario
>
> Unknown
>
>
>
>
>
>
>
> # http://atpworldtour.com
>
>
>
> /*
>
> * Stores hash values for localization.
>
> * Will need duplicating for each language.
>
> */
>
>
>
> if (typeof registerNS == "undefined") {
>
>     function registerNS(ns) {
>
>         var nsParts = ns.split(".");
>
>         var root = window;
>
>         for (var i = 0; i < nsParts.length; i++) {
>
>             if (typeof root[nsParts[i]] == "undefined")
>
>                 root[nsParts[i]] = new Object();
>
>             root = root[nsParts[i]];
>
>         }
>
>     }
>
> }
>
>
>
> registerNS("atp.utilities");
>
> // called repeatedly after this.
>
>
>
> ## Scenario
>
>
>
> Entire site is unusable.
>
>
>
>
>
>
>
>
>
> # http://atwiki.jp
>
>
>
> if (typeof AddClipsFlag == "undefined") {
>
>     var AddClipsFlag = 'addclips';
>
>     // ...
>
>     function AddClipsLoad() { /* ... */ }
>
>     // ...
>
> }
>
>
>
> AddClipsLoad();
>
>
>
> ## Scenario
>
>
>
> RSS functionality broken. This appears to be a library of some kind (see
> www.addclips.org).
>
>
>
>
>
>
>
> # Library: qTip 1.0:
> https://github.com/Craga89/qTip1/blob/master/1.0.0-rc3/jquery.qtip-1.0.0-rc3.js
> as seen on Zoompanel.com
>
>
>
> if (t.options.hide.when.event == "inactive") {
>
>     function y(z) {
>
>
>
>     }
>
> } else {
>
>     // ...
>
> }
>
> function x(z) {
>
>     if (t.options.hide.when.event == "inactive") {
>
>         y()
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Used on zoompanel.com. Tooltips will never disappear after showing up.
>
>
>
>
>
> # Library: thickbox 3 (http://thickbox.net/), in use on runescape.com and
> baixaki.com.br if (!(TB_PrevHTML === "")) {
>
>     function goPrev(){
>
>     }
>
>     $("#TB_prev").click(goPrev);
>
> }
>
>
>
> if (!(TB_NextHTML === "")) {
>
>     function goNext(){
>
>     }
>
>     $("#TB_next").click(goNext);
>
>
>
> }
>
>
>
> document.onkeydown = function (e) {
>
>     if (keycode == 190) { // display previous image
>
>         if (!(TB_NextHTML == "")) {
>
>             document.onkeydown = "";
>
>             goNext();
>
>         }
>
>     } else if (keycode == 188) { // display next image
>
>         if (!(TB_PrevHTML == "")) {
>
>             document.onkeydown = "";
>
>             goPrev();
>
>         }
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Going back/forward with keyboard is broken.
>
>
>
>
>
>
>
>
>
> # http://kankan.com
>
> Snippet
>
> if (typeof getCookie == 'undefined') {
>
>     function getCookie(name) {
>
>
>
>     }
>
> }
>
>
>
> // ...
>
>
>
> if (getCookie('tpar')) {
>
>     var irStartTime = new Date().getTime();
>
>     window.attachEvent('onunload', irTimeStat); }
>
>
>
> ## Scenario
>
> Unknown, possibly just for tracking purposes.
>
>
>
>
>
> # Google +1 library (only seen on TMZ.com, possibly this lib is out of date)
> try {
>
>     function h(a) {
>
>         throw a;
>
>     }
>
>     // plus a ton of other decls
>
> } catch (e) { }
>
>
>
> try {
>
>     h(Error("foo"));
>
>     // plus a ton of calls to other block scoped functions } catch (e) { }
>
>
>
> ## Scenario
>
>
>
> Plus one button is broken.
>
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Rick Waldron


On Wednesday, December 26, 2012, Mark S. Miller wrote:
Hi Brian, thanks for accumulating this data!

Between
* this data,
* Apple's decision as recorded at
<https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
* the new function syntax micro-modes,
* and the "let" issues already discussed,
I reiterate that we should stop trying to twist the language to
somehow shoehorn ES6 features into non-strict mode.

For both "function" and "let", when we first discussed trying to
retrofit sense into ES6 non-strict mode, we knew that this was
speculative, because non-strict mode cannot include web-breaking
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including "let" and nested "function", should be
available only in strict mode. For new function syntax, if
shoe-horning it into non-strict mode requires micro-modes as
previously discussed, then we shouldn't. Whatever the complaints about
living with one mode distinction, we're certainly not addressing these
complaints by introducing more mode distinctions.

Proclaiming 1JS has failed just because we've learned that block scoped function declarations (arguably an awful and unnecessary idea) is counter-productive rhetoric. 1JS is more important than this "feature" and like typeof null === "null", I'd rather abandon the one feature for the greater good. 

Rick 



On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
<[hidden email]> wrote:
> I have some data on patterns and sites that may break due to the proposed
> change to semantics of function decls in block scope. I am not advocating
> for any changes here but merely dumping some data I’ve gathered. I will
> continue gathering data about this breaking change and potentially others
> (eg. let[x] = 1), so any further data you folks are interested in let me
> know. I think the January meeting would be a good venue to discuss any of
> this in detail if warranted.
>
> On December 17th, 2235 sites were crawled and their scripts downloaded.
> These scripts were then processed in an attempt to identify likely breakages
> due to the change to the semantics of func decls in block scope. In this
> dataset, 4% of the scripts contained a function declaration in block scope
> (mostly inside if and try, although pretty much every node contains a
> function somewhere in this dataset). However, most of these scripts use the
> function within the same block and so won’t be broken. 20 sites, however,
> will likely be broken by this change in some way. There is also a chance
> that the tool used to identify breakages has missed some code that will
> breka.
>
>
>
> Below are some examples of code on the web today that will be broken. For
> each I include a snippet of code that is heavily edited in an attempt to
> convey the pattern used and the developer intent. I also attempt to identify
> what functionality will actually be broken.
>
>
>
> Most of the breakages occur in non-library code, with two exceptions: qTip
> 1.0, and thickbox 3.
>
>
>
> # http://ninemsn.com.au
>
>
>
> RenderModal = function () {
>
>     if (x) { // is an array of shortcuts that can be added. Is statically
> non-empty.
>
>         function K() {
>
>             // process the array of shortcuts in some way
>
>         }
>
>     }
>
>     K();
>
> };
>
>
>
> ## Scenario
>
>
>
> 1.       Navigate to main page.
>
> 2.       Click “Add other shortcuts”
>
> 3.       Click “View more shortcuts” – this will not work.
>
>
>
>
>
> # http://yandex.ru
>
>
>
> if (_ycssjs("BaH0Fmmo2Sg24lRmTPrK0B8qpaA")) {
>
>     function cp(g, c, d) { /* ...*/ }
>
>
>
>     function csh_ifgsid(c, b) { /*...*/ } }
>
>
>
> // ... thousands of lines of code ...
>
>
>
>
>
> if (_ycssjs("rO+QIoSf2L0NwDn6vjJjy+27nxI")) {
>
>     function news() {
>
>         csh_if_gsid();
>
>     }
>
> }
>
>
>
> if (_ycssjs("YRPF0QVjJmhRiKRu6cvi3YXqYo8")) {
>
>     // ... bunch of stuff ...
>
>     cp();
>
> }
>
>
>
> ## Scenario
>
>
>
> Unknown
>
>
>
>
>
> # http://g.espncdn.com/nfl-primetime-payoff/en/module/entry?matchupid=478
>
>
>
> if (isIE && isWin) {
>
>     // ...
>
> } else {
>
>     function JSGetSwfVer(i){
>
>         // ...
>
>     }
>
> }
>
>
>
> function checkFlash(myRev) {
>
>     // ...
>
>
>
>     if (isIE && isWin) {
>
>         // ...
>
>     } else {
>
>         aV = JSGetSwfVer(rV);
>
>     }
>
>
>
> }
>
>
>
> ## Scenario
>
>
>
> Can’t find a page which uses this code.
>
>
>
>
>
> # http://www.t-online.de
>
>
>
> if (!Adition_Environment) {
>
>     var Adition_Environment = (function () {
>
>         var _this = {};
>
>         // ...
>
>         _this.getPrf = function (cuId) {
>
>             var prf = "";
>
>             try {
>
>                 prf = Adition_Prfstr(cuId);
>
>             } catch (e) { }
>
>             return prf;
>
>         };
>
>         // ...
>
>     })();
>
> }
>
>
>
> // snip 1k lines
>
> if (typeof Adition_Prfstr == "undefined") {
>
>     function Adition_Prfstr(ADITION_CONTENTUNIT_ID) {
>
>         // ...
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Required to display advertisements on the page.
>
>
>
>
>
>
>
> # http://manormystery.com
>
>
>
> if (!window._ate) {
>
>     window._ate = { /* ... */ };
>
>     function addthis_open() { /* ... */ } } else { _ate.inst++; }
>
>
>
> if (_atc.abf) {
>
>     addthis_open(document.getElementById("ab"), "emailab",
> window.addthis_url || "[URL]", window.addthis_title || "[TITLE]"); }
>
>
>
> ## Scenario
>
>
>
> Social sharing popups broken at least. This may be a general utility used in
> a number of places.
>
>
>
>
>
>
>
> # http://manhunt.net (NSFW, DO NOT VISIT AT WORK)
>
>
>
> /** @todo isFlashInstalled() should probably be gotten by include from
> js/cmmn/flashDetect.js or upfunc.js. */
>
>
>
> if (typeof isFlashInstalled == 'undefined') {
>
>     function isFlashInstalled() {
>
>         var requiredMajorVersion = 6; // Major version of Flash required
>
>         var requiredMinorVersion = 0;   // Minor version of Flash required
>
>         var requiredRevision = 0;   // Minor version of Flash required
>
>         var s = new SWFObject();
>
>         if (!s) return false;
>
>         var version = s.installedVer;
>
>         if (!version) return false;
>
>         return (version.major >= requiredMajorVersion && version.minor >=
> requiredMinorVersion && version.rev >= requiredRevision);
>
>     }
>
> }
>
> isFlashInstalled();
>
>
>
> ## Scenario
>
>
>
> I avoided this site at work for obvious reasons, but it looks like all login
> functionality will be broken.
>
>
>
>
>
>
>
>
>
> # http://www.163.com
>
>
>
> NTESAD_Couplet.prototype = {
>
>     NTESCreate: function () {
>
>
>
>         var widthsmall = this.options.widthsmall;
>
>         var width = this.options.width;
>
>
>
>         if (this.options.leftbig != "" && this.options.leftsmall != "") {
>
>             function bighide() {
>
>                 coupletLeft.style.display = "none";
>
>                 coupletLeftsmall.style.display = "block";
>
>             }
>
>
>
>             function smallhide() {
>
>                 coupletLeftsmall.style.display = "none";
>
>                 coupletLeft.style.display = "block";
>
>             }
>
>         }
>
>
>
>         if (this.options.rightbig != "" && this.options.rightsmall != "") {
>
>             function Rbighide() {
>
>                 coupletRight.style.display = "none";
>
>                 coupletRightsmall.style.display = "block";
>
>             }
>
>         }
>
>
>
>         if (this.NTESPosition()) {
>
>             if (this.options.leftbig != "" && this.options.leftsmall != ""
> && this.options.rightbig != "" && this.options.rightsmall != "") {
>
>                 this.NTESBind(coupletclose, "click", function () {
> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
> coupletLeftsmall.style.display = "none"; });
>
>                 this.NTESBind(coupletclose2, "click", function () {
> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
> coupletLeftsmall.style.display = "none"; });
>
>             }
>
>         }
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Unknown.
>
>
>
>
>
>
>
> # http://www22.verizon.com
>
>
>
> if (floatStyle.match(/Content/)) {
>
>     var contentDiv = d.getElementById(_b.Preferences.Render.main_content_id
> || "content");
>
>     if (contentDiv == null) {
>
>         floatStyle = this.Preferences.Render.float_style = 'fixed'
>
>     }
>
>     function getRightOfContent() {
>
>         return contentDiv.offsetWidth + contentDiv.offsetLeft + 1
>
>     }
>
>     function fixBackground() {
>
>         if (_b.Preferences.Render.fix_background) {
>
>             db.style.backgroundAttachment = "scroll";
>
>             var margin = null;
>
>             if (document.defaultView &&
> document.defaultView.getComputedStyle) {
>
>                 margin =
> parseInt(document.defaultView.getComputedStyle(contentDiv,
> null).getPropertyValue("margin-left"), 10)
>
>             } else {
>
>                 margin = parseInt(contentDiv.currentStyle.marginLeft, 10)
>
>             }
>
>             if (isNaN(margin) || margin == 0) {
>
>                 margin = contentDiv.offsetLeft || 0
>
>             }
>
>             db.style.backgroundPosition = (Math.floor(contentDiv.scrollWidth
> * -0.5) - 2 + margin) + 'px 0'
>
>         }
>
>     }
>
> }
>
>
>
> // getRightOfContent/fixBackground used repeatedly after this.
>
>
>
> ## Scenario
>
>
>
> Couldn’t find a scenario where this code was hit, but the site is expansive.
> Also, the above code is found in at least 2 different scripts across the
> site.
>
>
>
>
>
>
>
>
>
> # http://www.jeuxvideo.com
>
>
>
> if (typeof getAppNexusMegaTag == 'undefined' || typeof getAppNexusMegaTag !=
> 'function') {
>
>     function getSize1080667() {
>
>         return '250x250';
>
>     }
>
> }
>
>
>
> if (typeof inFIF != "undefined" && inFIF == true) {
>
>     try {
>
>         parent.getSize1080667 = getSize1080667;
>
>     } catch (e) { }
>
> }
>
>
>
>
>
> ## Scenario
>
> Ad won’t display.
>
>
>
>
>
>
>
> # http://msn.foxsports.com
>
> /* this function is much faster, so if possible we use it. Some IEs are the
> only ones I know of that need the idiotic second function, generated by an
> if clause.  */ function add32(a, b) {
>
>     return (a + b) & 0xFFFFFFFF;
>
> }
>
>
>
> if (md5('hello') != '5d41402abc4b2a76b9719d911017c592') {
>
>     function add32(x, y) {
>
>         var lsw = (x & 0xFFFF) + (y & 0xFFFF),
>
>             msw = (x >> 16) + (y >> 16) + (lsw >> 16);
>
>         return (msw << 16) | (lsw & 0xFFFF);
>
>     }
>
> }
>
>
>
> ## Scenario
>
>
>
> Nothing is necessary broken about this, as long as the first add32 functions
> properly (today everyone with this code is using the second function). This
> is a fairly common MD5 library (do a search for “idiotic second function” to
> get an idea, however this was only found once in the dataset).
>
>
>
>
>
>
>
>
>
>
>
> # http://iwiw.hu/i/belepes
>
>
>
> (function () {
>
>     if (jQuery.fn.lazyload) {
>
>         function a() {
>
>             return typeof f !== "undefined" ? f : (f =
> jQuery("body").hasClass("lazyloadimages"))
>
>         }
>
>     }
>
>     jQuery(function () {
>
>         if (a()) {
>
>             d.apply(document.body)<

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Dave Herman
In reply to this post by Mark S. Miller-2
Well, before I start arguing with you, I'd like to know what argument you're making. ;-)

Are you saying we should go back to having a MIME-type (and/or pragma) opt-in? Your subject line suggests that. Or are you saying we should simply not support some of the new features in non-strict code? Because your points only seem to be arguing for the latter, not the former.

I think the MIME type idea, while obviously attractive for our purposes, would've had terrible consequences for programmers, and I really hope we don't have to relitigate that debate.

Dave

On Dec 26, 2012, at 2:03 PM, Mark S. Miller <[hidden email]> wrote:

> Hi Brian, thanks for accumulating this data!
>
> Between
> * this data,
> * Apple's decision as recorded at
> <https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
> * the new function syntax micro-modes,
> * and the "let" issues already discussed,
> I reiterate that we should stop trying to twist the language to
> somehow shoehorn ES6 features into non-strict mode.
>
> For both "function" and "let", when we first discussed trying to
> retrofit sense into ES6 non-strict mode, we knew that this was
> speculative, because non-strict mode cannot include web-breaking
> incompatible changes. This experiment has failed, so we should now
> return to plan A. Any ES6 features that don't fit into non-strict mode
> without contortion, including "let" and nested "function", should be
> available only in strict mode. For new function syntax, if
> shoe-horning it into non-strict mode requires micro-modes as
> previously discussed, then we shouldn't. Whatever the complaints about
> living with one mode distinction, we're certainly not addressing these
> complaints by introducing more mode distinctions.
>
>
>
> On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
> <[hidden email]> wrote:
>> I have some data on patterns and sites that may break due to the proposed
>> change to semantics of function decls in block scope. I am not advocating
>> for any changes here but merely dumping some data I’ve gathered. I will
>> continue gathering data about this breaking change and potentially others
>> (eg. let[x] = 1), so any further data you folks are interested in let me
>> know. I think the January meeting would be a good venue to discuss any of
>> this in detail if warranted.
>>
>> On December 17th, 2235 sites were crawled and their scripts downloaded.
>> These scripts were then processed in an attempt to identify likely breakages
>> due to the change to the semantics of func decls in block scope. In this
>> dataset, 4% of the scripts contained a function declaration in block scope
>> (mostly inside if and try, although pretty much every node contains a
>> function somewhere in this dataset). However, most of these scripts use the
>> function within the same block and so won’t be broken. 20 sites, however,
>> will likely be broken by this change in some way. There is also a chance
>> that the tool used to identify breakages has missed some code that will
>> breka.
>>
>>
>>
>> Below are some examples of code on the web today that will be broken. For
>> each I include a snippet of code that is heavily edited in an attempt to
>> convey the pattern used and the developer intent. I also attempt to identify
>> what functionality will actually be broken.
>>
>>
>>
>> Most of the breakages occur in non-library code, with two exceptions: qTip
>> 1.0, and thickbox 3.
>>
>>
>>
>> # http://ninemsn.com.au
>>
>>
>>
>> RenderModal = function () {
>>
>>    if (x) { // is an array of shortcuts that can be added. Is statically
>> non-empty.
>>
>>        function K() {
>>
>>            // process the array of shortcuts in some way
>>
>>        }
>>
>>    }
>>
>>    K();
>>
>> };
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> 1.       Navigate to main page.
>>
>> 2.       Click “Add other shortcuts”
>>
>> 3.       Click “View more shortcuts” – this will not work.
>>
>>
>>
>>
>>
>> # http://yandex.ru
>>
>>
>>
>> if (_ycssjs("BaH0Fmmo2Sg24lRmTPrK0B8qpaA")) {
>>
>>    function cp(g, c, d) { /* ...*/ }
>>
>>
>>
>>    function csh_ifgsid(c, b) { /*...*/ } }
>>
>>
>>
>> // ... thousands of lines of code ...
>>
>>
>>
>>
>>
>> if (_ycssjs("rO+QIoSf2L0NwDn6vjJjy+27nxI")) {
>>
>>    function news() {
>>
>>        csh_if_gsid();
>>
>>    }
>>
>> }
>>
>>
>>
>> if (_ycssjs("YRPF0QVjJmhRiKRu6cvi3YXqYo8")) {
>>
>>    // ... bunch of stuff ...
>>
>>    cp();
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Unknown
>>
>>
>>
>>
>>
>> # http://g.espncdn.com/nfl-primetime-payoff/en/module/entry?matchupid=478
>>
>>
>>
>> if (isIE && isWin) {
>>
>>    // ...
>>
>> } else {
>>
>>    function JSGetSwfVer(i){
>>
>>        // ...
>>
>>    }
>>
>> }
>>
>>
>>
>> function checkFlash(myRev) {
>>
>>    // ...
>>
>>
>>
>>    if (isIE && isWin) {
>>
>>        // ...
>>
>>    } else {
>>
>>        aV = JSGetSwfVer(rV);
>>
>>    }
>>
>>
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Can’t find a page which uses this code.
>>
>>
>>
>>
>>
>> # http://www.t-online.de
>>
>>
>>
>> if (!Adition_Environment) {
>>
>>    var Adition_Environment = (function () {
>>
>>        var _this = {};
>>
>>        // ...
>>
>>        _this.getPrf = function (cuId) {
>>
>>            var prf = "";
>>
>>            try {
>>
>>                prf = Adition_Prfstr(cuId);
>>
>>            } catch (e) { }
>>
>>            return prf;
>>
>>        };
>>
>>        // ...
>>
>>    })();
>>
>> }
>>
>>
>>
>> // snip 1k lines
>>
>> if (typeof Adition_Prfstr == "undefined") {
>>
>>    function Adition_Prfstr(ADITION_CONTENTUNIT_ID) {
>>
>>        // ...
>>
>>    }
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Required to display advertisements on the page.
>>
>>
>>
>>
>>
>>
>>
>> # http://manormystery.com
>>
>>
>>
>> if (!window._ate) {
>>
>>    window._ate = { /* ... */ };
>>
>>    function addthis_open() { /* ... */ } } else { _ate.inst++; }
>>
>>
>>
>> if (_atc.abf) {
>>
>>    addthis_open(document.getElementById("ab"), "emailab",
>> window.addthis_url || "[URL]", window.addthis_title || "[TITLE]"); }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Social sharing popups broken at least. This may be a general utility used in
>> a number of places.
>>
>>
>>
>>
>>
>>
>>
>> # http://manhunt.net (NSFW, DO NOT VISIT AT WORK)
>>
>>
>>
>> /** @todo isFlashInstalled() should probably be gotten by include from
>> js/cmmn/flashDetect.js or upfunc.js. */
>>
>>
>>
>> if (typeof isFlashInstalled == 'undefined') {
>>
>>    function isFlashInstalled() {
>>
>>        var requiredMajorVersion = 6; // Major version of Flash required
>>
>>        var requiredMinorVersion = 0;   // Minor version of Flash required
>>
>>        var requiredRevision = 0;   // Minor version of Flash required
>>
>>        var s = new SWFObject();
>>
>>        if (!s) return false;
>>
>>        var version = s.installedVer;
>>
>>        if (!version) return false;
>>
>>        return (version.major >= requiredMajorVersion && version.minor >=
>> requiredMinorVersion && version.rev >= requiredRevision);
>>
>>    }
>>
>> }
>>
>> isFlashInstalled();
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> I avoided this site at work for obvious reasons, but it looks like all login
>> functionality will be broken.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://www.163.com
>>
>>
>>
>> NTESAD_Couplet.prototype = {
>>
>>    NTESCreate: function () {
>>
>>
>>
>>        var widthsmall = this.options.widthsmall;
>>
>>        var width = this.options.width;
>>
>>
>>
>>        if (this.options.leftbig != "" && this.options.leftsmall != "") {
>>
>>            function bighide() {
>>
>>                coupletLeft.style.display = "none";
>>
>>                coupletLeftsmall.style.display = "block";
>>
>>            }
>>
>>
>>
>>            function smallhide() {
>>
>>                coupletLeftsmall.style.display = "none";
>>
>>                coupletLeft.style.display = "block";
>>
>>            }
>>
>>        }
>>
>>
>>
>>        if (this.options.rightbig != "" && this.options.rightsmall != "") {
>>
>>            function Rbighide() {
>>
>>                coupletRight.style.display = "none";
>>
>>                coupletRightsmall.style.display = "block";
>>
>>            }
>>
>>        }
>>
>>
>>
>>        if (this.NTESPosition()) {
>>
>>            if (this.options.leftbig != "" && this.options.leftsmall != ""
>> && this.options.rightbig != "" && this.options.rightsmall != "") {
>>
>>                this.NTESBind(coupletclose, "click", function () {
>> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>> coupletLeftsmall.style.display = "none"; });
>>
>>                this.NTESBind(coupletclose2, "click", function () {
>> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>> coupletLeftsmall.style.display = "none"; });
>>
>>            }
>>
>>        }
>>
>>    }
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Unknown.
>>
>>
>>
>>
>>
>>
>>
>> # http://www22.verizon.com
>>
>>
>>
>> if (floatStyle.match(/Content/)) {
>>
>>    var contentDiv = d.getElementById(_b.Preferences.Render.main_content_id
>> || "content");
>>
>>    if (contentDiv == null) {
>>
>>        floatStyle = this.Preferences.Render.float_style = 'fixed'
>>
>>    }
>>
>>    function getRightOfContent() {
>>
>>        return contentDiv.offsetWidth + contentDiv.offsetLeft + 1
>>
>>    }
>>
>>    function fixBackground() {
>>
>>        if (_b.Preferences.Render.fix_background) {
>>
>>            db.style.backgroundAttachment = "scroll";
>>
>>            var margin = null;
>>
>>            if (document.defaultView &&
>> document.defaultView.getComputedStyle) {
>>
>>                margin =
>> parseInt(document.defaultView.getComputedStyle(contentDiv,
>> null).getPropertyValue("margin-left"), 10)
>>
>>            } else {
>>
>>                margin = parseInt(contentDiv.currentStyle.marginLeft, 10)
>>
>>            }
>>
>>            if (isNaN(margin) || margin == 0) {
>>
>>                margin = contentDiv.offsetLeft || 0
>>
>>            }
>>
>>            db.style.backgroundPosition = (Math.floor(contentDiv.scrollWidth
>> * -0.5) - 2 + margin) + 'px 0'
>>
>>        }
>>
>>    }
>>
>> }
>>
>>
>>
>> // getRightOfContent/fixBackground used repeatedly after this.
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Couldn’t find a scenario where this code was hit, but the site is expansive.
>> Also, the above code is found in at least 2 different scripts across the
>> site.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://www.jeuxvideo.com
>>
>>
>>
>> if (typeof getAppNexusMegaTag == 'undefined' || typeof getAppNexusMegaTag !=
>> 'function') {
>>
>>    function getSize1080667() {
>>
>>        return '250x250';
>>
>>    }
>>
>> }
>>
>>
>>
>> if (typeof inFIF != "undefined" && inFIF == true) {
>>
>>    try {
>>
>>        parent.getSize1080667 = getSize1080667;
>>
>>    } catch (e) { }
>>
>> }
>>
>>
>>
>>
>>
>> ## Scenario
>>
>> Ad won’t display.
>>
>>
>>
>>
>>
>>
>>
>> # http://msn.foxsports.com
>>
>> /* this function is much faster, so if possible we use it. Some IEs are the
>> only ones I know of that need the idiotic second function, generated by an
>> if clause.  */ function add32(a, b) {
>>
>>    return (a + b) & 0xFFFFFFFF;
>>
>> }
>>
>>
>>
>> if (md5('hello') != '5d41402abc4b2a76b9719d911017c592') {
>>
>>    function add32(x, y) {
>>
>>        var lsw = (x & 0xFFFF) + (y & 0xFFFF),
>>
>>            msw = (x >> 16) + (y >> 16) + (lsw >> 16);
>>
>>        return (msw << 16) | (lsw & 0xFFFF);
>>
>>    }
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Nothing is necessary broken about this, as long as the first add32 functions
>> properly (today everyone with this code is using the second function). This
>> is a fairly common MD5 library (do a search for “idiotic second function” to
>> get an idea, however this was only found once in the dataset).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://iwiw.hu/i/belepes
>>
>>
>>
>> (function () {
>>
>>    if (jQuery.fn.lazyload) {
>>
>>        function a() {
>>
>>            return typeof f !== "undefined" ? f : (f =
>> jQuery("body").hasClass("lazyloadimages"))
>>
>>        }
>>
>>    }
>>
>>    jQuery(function () {
>>
>>        if (a()) {
>>
>>            d.apply(document.body)
>>
>>        }
>>
>>    })
>>
>> })();
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Unknown
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://www.laposte.net
>>
>>
>>
>> if (!window.$extend) {
>>
>>    function $extend(c, a) {
>>
>>        for (var b in (a || {})) {
>>
>>            c[b] = a[b]
>>
>>        } return c
>>
>>    }
>>
>> }
>>
>> // $extend used repeatedly after this
>>
>>
>>
>> ## Scenario
>>
>> Unknown
>>
>>
>>
>>
>>
>>
>>
>> # http://atpworldtour.com
>>
>>
>>
>> /*
>>
>> * Stores hash values for localization.
>>
>> * Will need duplicating for each language.
>>
>> */
>>
>>
>>
>> if (typeof registerNS == "undefined") {
>>
>>    function registerNS(ns) {
>>
>>        var nsParts = ns.split(".");
>>
>>        var root = window;
>>
>>        for (var i = 0; i < nsParts.length; i++) {
>>
>>            if (typeof root[nsParts[i]] == "undefined")
>>
>>                root[nsParts[i]] = new Object();
>>
>>            root = root[nsParts[i]];
>>
>>        }
>>
>>    }
>>
>> }
>>
>>
>>
>> registerNS("atp.utilities");
>>
>> // called repeatedly after this.
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Entire site is unusable.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://atwiki.jp
>>
>>
>>
>> if (typeof AddClipsFlag == "undefined") {
>>
>>    var AddClipsFlag = 'addclips';
>>
>>    // ...
>>
>>    function AddClipsLoad() { /* ... */ }
>>
>>    // ...
>>
>> }
>>
>>
>>
>> AddClipsLoad();
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> RSS functionality broken. This appears to be a library of some kind (see
>> www.addclips.org).
>>
>>
>>
>>
>>
>>
>>
>> # Library: qTip 1.0:
>> https://github.com/Craga89/qTip1/blob/master/1.0.0-rc3/jquery.qtip-1.0.0-rc3.js
>> as seen on Zoompanel.com
>>
>>
>>
>> if (t.options.hide.when.event == "inactive") {
>>
>>    function y(z) {
>>
>>
>>
>>    }
>>
>> } else {
>>
>>    // ...
>>
>> }
>>
>> function x(z) {
>>
>>    if (t.options.hide.when.event == "inactive") {
>>
>>        y()
>>
>>    }
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Used on zoompanel.com. Tooltips will never disappear after showing up.
>>
>>
>>
>>
>>
>> # Library: thickbox 3 (http://thickbox.net/), in use on runescape.com and
>> baixaki.com.br if (!(TB_PrevHTML === "")) {
>>
>>    function goPrev(){
>>
>>    }
>>
>>    $("#TB_prev").click(goPrev);
>>
>> }
>>
>>
>>
>> if (!(TB_NextHTML === "")) {
>>
>>    function goNext(){
>>
>>    }
>>
>>    $("#TB_next").click(goNext);
>>
>>
>>
>> }
>>
>>
>>
>> document.onkeydown = function (e) {
>>
>>    if (keycode == 190) { // display previous image
>>
>>        if (!(TB_NextHTML == "")) {
>>
>>            document.onkeydown = "";
>>
>>            goNext();
>>
>>        }
>>
>>    } else if (keycode == 188) { // display next image
>>
>>        if (!(TB_PrevHTML == "")) {
>>
>>            document.onkeydown = "";
>>
>>            goPrev();
>>
>>        }
>>
>>    }
>>
>> }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Going back/forward with keyboard is broken.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # http://kankan.com
>>
>> Snippet
>>
>> if (typeof getCookie == 'undefined') {
>>
>>    function getCookie(name) {
>>
>>
>>
>>    }
>>
>> }
>>
>>
>>
>> // ...
>>
>>
>>
>> if (getCookie('tpar')) {
>>
>>    var irStartTime = new Date().getTime();
>>
>>    window.attachEvent('onunload', irTimeStat); }
>>
>>
>>
>> ## Scenario
>>
>> Unknown, possibly just for tracking purposes.
>>
>>
>>
>>
>>
>> # Google +1 library (only seen on TMZ.com, possibly this lib is out of date)
>> try {
>>
>>    function h(a) {
>>
>>        throw a;
>>
>>    }
>>
>>    // plus a ton of other decls
>>
>> } catch (e) { }
>>
>>
>>
>> try {
>>
>>    h(Error("foo"));
>>
>>    // plus a ton of calls to other block scoped functions } catch (e) { }
>>
>>
>>
>> ## Scenario
>>
>>
>>
>> Plus one button is broken.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>    Cheers,
>    --MarkM
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Mark S. Miller-2
In reply to this post by Rick Waldron
Hi Rick, I cited four "features". Blocked scoped functions are simply
the straw that makes the condition of the camel's back more obvious.

As for the greater good, we're all working for that. We just differ on
which path leads there.

On Wed, Dec 26, 2012 at 2:25 PM, Rick Waldron <[hidden email]> wrote:

>
>
> On Wednesday, December 26, 2012, Mark S. Miller wrote:
>>
>> Hi Brian, thanks for accumulating this data!
>>
>> Between
>> * this data,
>> * Apple's decision as recorded at
>> <https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
>> * the new function syntax micro-modes,
>> * and the "let" issues already discussed,
>> I reiterate that we should stop trying to twist the language to
>> somehow shoehorn ES6 features into non-strict mode.
>>
>> For both "function" and "let", when we first discussed trying to
>> retrofit sense into ES6 non-strict mode, we knew that this was
>> speculative, because non-strict mode cannot include web-breaking
>> incompatible changes. This experiment has failed, so we should now
>> return to plan A. Any ES6 features that don't fit into non-strict mode
>> without contortion, including "let" and nested "function", should be
>> available only in strict mode. For new function syntax, if
>> shoe-horning it into non-strict mode requires micro-modes as
>> previously discussed, then we shouldn't. Whatever the complaints about
>> living with one mode distinction, we're certainly not addressing these
>> complaints by introducing more mode distinctions.
>
>
> Proclaiming 1JS has failed just because we've learned that block scoped
> function declarations (arguably an awful and unnecessary idea) is
> counter-productive rhetoric. 1JS is more important than this "feature" and
> like typeof null === "null", I'd rather abandon the one feature for the
> greater good.
>
> Rick
>>
>>
>>
>>
>> On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
>> <[hidden email]> wrote:
>> > I have some data on patterns and sites that may break due to the
>> > proposed
>> > change to semantics of function decls in block scope. I am not
>> > advocating
>> > for any changes here but merely dumping some data I’ve gathered. I will
>> > continue gathering data about this breaking change and potentially
>> > others
>> > (eg. let[x] = 1), so any further data you folks are interested in let me
>> > know. I think the January meeting would be a good venue to discuss any
>> > of
>> > this in detail if warranted.
>> >
>> > On December 17th, 2235 sites were crawled and their scripts downloaded.
>> > These scripts were then processed in an attempt to identify likely
>> > breakages
>> > due to the change to the semantics of func decls in block scope. In this
>> > dataset, 4% of the scripts contained a function declaration in block
>> > scope
>> > (mostly inside if and try, although pretty much every node contains a
>> > function somewhere in this dataset). However, most of these scripts use
>> > the
>> > function within the same block and so won’t be broken. 20 sites,
>> > however,
>> > will likely be broken by this change in some way. There is also a chance
>> > that the tool used to identify breakages has missed some code that will
>> > breka.
>> >
>> >
>> >
>> > Below are some examples of code on the web today that will be broken.
>> > For
>> > each I include a snippet of code that is heavily edited in an attempt to
>> > convey the pattern used and the developer intent. I also attempt to
>> > identify
>> > what functionality will actually be broken.
>> >
>> >
>> >
>> > Most of the breakages occur in non-library code, with two exceptions:
>> > qTip
>> > 1.0, and thickbox 3.
>> >
>> >
>> >
>> > # http://ninemsn.com.au
>> >
>> >
>> >
>> > RenderModal = function () {
>> >
>> >     if (x) { // is an array of shortcuts that can be added. Is
>> > statically
>> > non-empty.
>> >
>> >         function K() {
>> >
>> >             // process the array of shortcuts in some way
>> >
>> >         }
>> >
>> >     }
>> >
>> >     K();
>> >
>> > };
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > 1.       Navigate to main page.
>> >
>> > 2.       Click “Add other shortcuts”
>> >
>> > 3.       Click “View more shortcuts” – this will not work.
>> >
>> >
>> >
>> >
>> >
>> > # http://yandex.ru
>> >
>> >
>> >
>> > if (_ycssjs("BaH0Fmmo2Sg24lRmTPrK0B8qpaA")) {
>> >
>> >     function cp(g, c, d) { /* ...*/ }
>> >
>> >
>> >
>> >     function csh_ifgsid(c, b) { /*...*/ } }
>> >
>> >
>> >
>> > // ... thousands of lines of code ...
>> >
>> >
>> >
>> >
>> >
>> > if (_ycssjs("rO+QIoSf2L0NwDn6vjJjy+27nxI")) {
>> >
>> >     function news() {
>> >
>> >         csh_if_gsid();
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > if (_ycssjs("YRPF0QVjJmhRiKRu6cvi3YXqYo8")) {
>> >
>> >     // ... bunch of stuff ...
>> >
>> >     cp();
>> >
>> > }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Unknown
>> >
>> >
>> >
>> >
>> >
>> > #
>> > http://g.espncdn.com/nfl-primetime-payoff/en/module/entry?matchupid=478
>> >
>> >
>> >
>> > if (isIE && isWin) {
>> >
>> >     // ...
>> >
>> > } else {
>> >
>> >     function JSGetSwfVer(i){
>> >
>> >         // ...
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > function checkFlash(myRev) {
>> >
>> >     // ...
>> >
>> >
>> >
>> >     if (isIE && isWin) {
>> >
>> >         // ...
>> >
>> >     } else {
>> >
>> >         aV = JSGetSwfVer(rV);
>> >
>> >     }
>> >
>> >
>> >
>> > }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Can’t find a page which uses this code.
>> >
>> >
>> >
>> >
>> >
>> > # http://www.t-online.de
>> >
>> >
>> >
>> > if (!Adition_Environment) {
>> >
>> >     var Adition_Environment = (function () {
>> >
>> >         var _this = {};
>> >
>> >         // ...
>> >
>> >         _this.getPrf = function (cuId) {
>> >
>> >             var prf = "";
>> >
>> >             try {
>> >
>> >                 prf = Adition_Prfstr(cuId);
>> >
>> >             } catch (e) { }
>> >
>> >             return prf;
>> >
>> >         };
>> >
>> >         // ...
>> >
>> >     })();
>> >
>> > }
>> >
>> >
>> >
>> > // snip 1k lines
>> >
>> > if (typeof Adition_Prfstr == "undefined") {
>> >
>> >     function Adition_Prfstr(ADITION_CONTENTUNIT_ID) {
>> >
>> >         // ...
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Required to display advertisements on the page.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://manormystery.com
>> >
>> >
>> >
>> > if (!window._ate) {
>> >
>> >     window._ate = { /* ... */ };
>> >
>> >     function addthis_open() { /* ... */ } } else { _ate.inst++; }
>> >
>> >
>> >
>> > if (_atc.abf) {
>> >
>> >     addthis_open(document.getElementById("ab"), "emailab",
>> > window.addthis_url || "[URL]", window.addthis_title || "[TITLE]"); }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Social sharing popups broken at least. This may be a general utility
>> > used in
>> > a number of places.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://manhunt.net (NSFW, DO NOT VISIT AT WORK)
>> >
>> >
>> >
>> > /** @todo isFlashInstalled() should probably be gotten by include from
>> > js/cmmn/flashDetect.js or upfunc.js. */
>> >
>> >
>> >
>> > if (typeof isFlashInstalled == 'undefined') {
>> >
>> >     function isFlashInstalled() {
>> >
>> >         var requiredMajorVersion = 6; // Major version of Flash required
>> >
>> >         var requiredMinorVersion = 0;   // Minor version of Flash
>> > required
>> >
>> >         var requiredRevision = 0;   // Minor version of Flash required
>> >
>> >         var s = new SWFObject();
>> >
>> >         if (!s) return false;
>> >
>> >         var version = s.installedVer;
>> >
>> >         if (!version) return false;
>> >
>> >         return (version.major >= requiredMajorVersion && version.minor
>> > >=
>> > requiredMinorVersion && version.rev >= requiredRevision);
>> >
>> >     }
>> >
>> > }
>> >
>> > isFlashInstalled();
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > I avoided this site at work for obvious reasons, but it looks like all
>> > login
>> > functionality will be broken.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://www.163.com
>> >
>> >
>> >
>> > NTESAD_Couplet.prototype = {
>> >
>> >     NTESCreate: function () {
>> >
>> >
>> >
>> >         var widthsmall = this.options.widthsmall;
>> >
>> >         var width = this.options.width;
>> >
>> >
>> >
>> >         if (this.options.leftbig != "" && this.options.leftsmall != "")
>> > {
>> >
>> >             function bighide() {
>> >
>> >                 coupletLeft.style.display = "none";
>> >
>> >                 coupletLeftsmall.style.display = "block";
>> >
>> >             }
>> >
>> >
>> >
>> >             function smallhide() {
>> >
>> >                 coupletLeftsmall.style.display = "none";
>> >
>> >                 coupletLeft.style.display = "block";
>> >
>> >             }
>> >
>> >         }
>> >
>> >
>> >
>> >         if (this.options.rightbig != "" && this.options.rightsmall !=
>> > "") {
>> >
>> >             function Rbighide() {
>> >
>> >                 coupletRight.style.display = "none";
>> >
>> >                 coupletRightsmall.style.display = "block";
>> >
>> >             }
>> >
>> >         }
>> >
>> >
>> >
>> >         if (this.NTESPosition()) {
>> >
>> >             if (this.options.leftbig != "" && this.options.leftsmall !=
>> > ""
>> > && this.options.rightbig != "" && this.options.rightsmall != "") {
>> >
>> >                 this.NTESBind(coupletclose, "click", function () {
>> > bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>> > coupletLeftsmall.style.display = "none"; });
>> >
>> >                 this.NTESBind(coupletclose2, "click", function () {
>> > bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>> > coupletLeftsmall.style.display = "none"; });
>> >
>> >             }
>> >
>> >         }
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Unknown.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://www22.verizon.com
>> >
>> >
>> >
>> > if (floatStyle.match(/Content/)) {
>> >
>> >     var contentDiv =
>> > d.getElementById(_b.Preferences.Render.main_content_id
>> > || "content");
>> >
>> >     if (contentDiv == null) {
>> >
>> >         floatStyle = this.Preferences.Render.float_style = 'fixed'
>> >
>> >     }
>> >
>> >     function getRightOfContent() {
>> >
>> >         return contentDiv.offsetWidth + contentDiv.offsetLeft + 1
>> >
>> >     }
>> >
>> >     function fixBackground() {
>> >
>> >         if (_b.Preferences.Render.fix_background) {
>> >
>> >             db.style.backgroundAttachment = "scroll";
>> >
>> >             var margin = null;
>> >
>> >             if (document.defaultView &&
>> > document.defaultView.getComputedStyle) {
>> >
>> >                 margin =
>> > parseInt(document.defaultView.getComputedStyle(contentDiv,
>> > null).getPropertyValue("margin-left"), 10)
>> >
>> >             } else {
>> >
>> >                 margin = parseInt(contentDiv.currentStyle.marginLeft,
>> > 10)
>> >
>> >             }
>> >
>> >             if (isNaN(margin) || margin == 0) {
>> >
>> >                 margin = contentDiv.offsetLeft || 0
>> >
>> >             }
>> >
>> >             db.style.backgroundPosition =
>> > (Math.floor(contentDiv.scrollWidth
>> > * -0.5) - 2 + margin) + 'px 0'
>> >
>> >         }
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > // getRightOfContent/fixBackground used repeatedly after this.
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Couldn’t find a scenario where this code was hit, but the site is
>> > expansive.
>> > Also, the above code is found in at least 2 different scripts across the
>> > site.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://www.jeuxvideo.com
>> >
>> >
>> >
>> > if (typeof getAppNexusMegaTag == 'undefined' || typeof
>> > getAppNexusMegaTag !=
>> > 'function') {
>> >
>> >     function getSize1080667() {
>> >
>> >         return '250x250';
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > if (typeof inFIF != "undefined" && inFIF == true) {
>> >
>> >     try {
>> >
>> >         parent.getSize1080667 = getSize1080667;
>> >
>> >     } catch (e) { }
>> >
>> > }
>> >
>> >
>> >
>> >
>> >
>> > ## Scenario
>> >
>> > Ad won’t display.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://msn.foxsports.com
>> >
>> > /* this function is much faster, so if possible we use it. Some IEs are
>> > the
>> > only ones I know of that need the idiotic second function, generated by
>> > an
>> > if clause.  */ function add32(a, b) {
>> >
>> >     return (a + b) & 0xFFFFFFFF;
>> >
>> > }
>> >
>> >
>> >
>> > if (md5('hello') != '5d41402abc4b2a76b9719d911017c592') {
>> >
>> >     function add32(x, y) {
>> >
>> >         var lsw = (x & 0xFFFF) + (y & 0xFFFF),
>> >
>> >             msw = (x >> 16) + (y >> 16) + (lsw >> 16);
>> >
>> >         return (msw << 16) | (lsw & 0xFFFF);
>> >
>> >     }
>> >
>> > }
>> >
>> >
>> >
>> > ## Scenario
>> >
>> >
>> >
>> > Nothing is necessary broken about this, as long as the first add32
>> > functions
>> > properly (today everyone with this code is using the second function).
>> > This
>> > is a fairly common MD5 library (do a search for “idiotic second
>> > function” to
>> > get an idea, however this was only found once in the dataset).
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > # http://iwiw.hu/i/belepes
>> >
>> >
>> >
>> > (function () {
>> >
>> >     if (jQuery.fn.lazyload) {
>> >
>> >         function a() {
>> >
>> >             return typeof f !== "undefined" ? f : (f =
>> > jQuery("body").hasClass("lazyloadimages"))
>> >
>> >         }
>> >
>> >     }
>> >
>> >     jQuery(function () {
>> >
>> >         if (a()) {
>> >
>> >             d.apply(document.body)<



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Mark S. Miller-2
In reply to this post by Dave Herman
On Wed, Dec 26, 2012 at 2:27 PM, David Herman <[hidden email]> wrote:
> Well, before I start arguing with you, I'd like to know what argument you're making. ;-)
>
> Are you saying we should go back to having a MIME-type (and/or pragma) opt-in? Your subject line suggests that. Or are you saying we should simply not support some of the new features in non-strict code? Because your points only seem to be arguing for the latter, not the former.

Sorry, I'd completely forgotten about those earlier options. I am
arguing only the latter. Specifically "Any ES6 features that don't fit
into non-strict mode without contortion, including "let" and nested
"function", should be available only in strict mode."



>
> I think the MIME type idea, while obviously attractive for our purposes, would've had terrible consequences for programmers, and I really hope we don't have to relitigate that debate.
>
> Dave
>
> On Dec 26, 2012, at 2:03 PM, Mark S. Miller <[hidden email]> wrote:
>
>> Hi Brian, thanks for accumulating this data!
>>
>> Between
>> * this data,
>> * Apple's decision as recorded at
>> <https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
>> * the new function syntax micro-modes,
>> * and the "let" issues already discussed,
>> I reiterate that we should stop trying to twist the language to
>> somehow shoehorn ES6 features into non-strict mode.
>>
>> For both "function" and "let", when we first discussed trying to
>> retrofit sense into ES6 non-strict mode, we knew that this was
>> speculative, because non-strict mode cannot include web-breaking
>> incompatible changes. This experiment has failed, so we should now
>> return to plan A. Any ES6 features that don't fit into non-strict mode
>> without contortion, including "let" and nested "function", should be
>> available only in strict mode. For new function syntax, if
>> shoe-horning it into non-strict mode requires micro-modes as
>> previously discussed, then we shouldn't. Whatever the complaints about
>> living with one mode distinction, we're certainly not addressing these
>> complaints by introducing more mode distinctions.
>>
>>
>>
>> On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
>> <[hidden email]> wrote:
>>> I have some data on patterns and sites that may break due to the proposed
>>> change to semantics of function decls in block scope. I am not advocating
>>> for any changes here but merely dumping some data I’ve gathered. I will
>>> continue gathering data about this breaking change and potentially others
>>> (eg. let[x] = 1), so any further data you folks are interested in let me
>>> know. I think the January meeting would be a good venue to discuss any of
>>> this in detail if warranted.
>>>
>>> On December 17th, 2235 sites were crawled and their scripts downloaded.
>>> These scripts were then processed in an attempt to identify likely breakages
>>> due to the change to the semantics of func decls in block scope. In this
>>> dataset, 4% of the scripts contained a function declaration in block scope
>>> (mostly inside if and try, although pretty much every node contains a
>>> function somewhere in this dataset). However, most of these scripts use the
>>> function within the same block and so won’t be broken. 20 sites, however,
>>> will likely be broken by this change in some way. There is also a chance
>>> that the tool used to identify breakages has missed some code that will
>>> breka.
>>>
>>>
>>>
>>> Below are some examples of code on the web today that will be broken. For
>>> each I include a snippet of code that is heavily edited in an attempt to
>>> convey the pattern used and the developer intent. I also attempt to identify
>>> what functionality will actually be broken.
>>>
>>>
>>>
>>> Most of the breakages occur in non-library code, with two exceptions: qTip
>>> 1.0, and thickbox 3.
>>>
>>>
>>>
>>> # http://ninemsn.com.au
>>>
>>>
>>>
>>> RenderModal = function () {
>>>
>>>    if (x) { // is an array of shortcuts that can be added. Is statically
>>> non-empty.
>>>
>>>        function K() {
>>>
>>>            // process the array of shortcuts in some way
>>>
>>>        }
>>>
>>>    }
>>>
>>>    K();
>>>
>>> };
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> 1.       Navigate to main page.
>>>
>>> 2.       Click “Add other shortcuts”
>>>
>>> 3.       Click “View more shortcuts” – this will not work.
>>>
>>>
>>>
>>>
>>>
>>> # http://yandex.ru
>>>
>>>
>>>
>>> if (_ycssjs("BaH0Fmmo2Sg24lRmTPrK0B8qpaA")) {
>>>
>>>    function cp(g, c, d) { /* ...*/ }
>>>
>>>
>>>
>>>    function csh_ifgsid(c, b) { /*...*/ } }
>>>
>>>
>>>
>>> // ... thousands of lines of code ...
>>>
>>>
>>>
>>>
>>>
>>> if (_ycssjs("rO+QIoSf2L0NwDn6vjJjy+27nxI")) {
>>>
>>>    function news() {
>>>
>>>        csh_if_gsid();
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> if (_ycssjs("YRPF0QVjJmhRiKRu6cvi3YXqYo8")) {
>>>
>>>    // ... bunch of stuff ...
>>>
>>>    cp();
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Unknown
>>>
>>>
>>>
>>>
>>>
>>> # http://g.espncdn.com/nfl-primetime-payoff/en/module/entry?matchupid=478
>>>
>>>
>>>
>>> if (isIE && isWin) {
>>>
>>>    // ...
>>>
>>> } else {
>>>
>>>    function JSGetSwfVer(i){
>>>
>>>        // ...
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> function checkFlash(myRev) {
>>>
>>>    // ...
>>>
>>>
>>>
>>>    if (isIE && isWin) {
>>>
>>>        // ...
>>>
>>>    } else {
>>>
>>>        aV = JSGetSwfVer(rV);
>>>
>>>    }
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Can’t find a page which uses this code.
>>>
>>>
>>>
>>>
>>>
>>> # http://www.t-online.de
>>>
>>>
>>>
>>> if (!Adition_Environment) {
>>>
>>>    var Adition_Environment = (function () {
>>>
>>>        var _this = {};
>>>
>>>        // ...
>>>
>>>        _this.getPrf = function (cuId) {
>>>
>>>            var prf = "";
>>>
>>>            try {
>>>
>>>                prf = Adition_Prfstr(cuId);
>>>
>>>            } catch (e) { }
>>>
>>>            return prf;
>>>
>>>        };
>>>
>>>        // ...
>>>
>>>    })();
>>>
>>> }
>>>
>>>
>>>
>>> // snip 1k lines
>>>
>>> if (typeof Adition_Prfstr == "undefined") {
>>>
>>>    function Adition_Prfstr(ADITION_CONTENTUNIT_ID) {
>>>
>>>        // ...
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Required to display advertisements on the page.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://manormystery.com
>>>
>>>
>>>
>>> if (!window._ate) {
>>>
>>>    window._ate = { /* ... */ };
>>>
>>>    function addthis_open() { /* ... */ } } else { _ate.inst++; }
>>>
>>>
>>>
>>> if (_atc.abf) {
>>>
>>>    addthis_open(document.getElementById("ab"), "emailab",
>>> window.addthis_url || "[URL]", window.addthis_title || "[TITLE]"); }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Social sharing popups broken at least. This may be a general utility used in
>>> a number of places.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://manhunt.net (NSFW, DO NOT VISIT AT WORK)
>>>
>>>
>>>
>>> /** @todo isFlashInstalled() should probably be gotten by include from
>>> js/cmmn/flashDetect.js or upfunc.js. */
>>>
>>>
>>>
>>> if (typeof isFlashInstalled == 'undefined') {
>>>
>>>    function isFlashInstalled() {
>>>
>>>        var requiredMajorVersion = 6; // Major version of Flash required
>>>
>>>        var requiredMinorVersion = 0;   // Minor version of Flash required
>>>
>>>        var requiredRevision = 0;   // Minor version of Flash required
>>>
>>>        var s = new SWFObject();
>>>
>>>        if (!s) return false;
>>>
>>>        var version = s.installedVer;
>>>
>>>        if (!version) return false;
>>>
>>>        return (version.major >= requiredMajorVersion && version.minor >=
>>> requiredMinorVersion && version.rev >= requiredRevision);
>>>
>>>    }
>>>
>>> }
>>>
>>> isFlashInstalled();
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> I avoided this site at work for obvious reasons, but it looks like all login
>>> functionality will be broken.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://www.163.com
>>>
>>>
>>>
>>> NTESAD_Couplet.prototype = {
>>>
>>>    NTESCreate: function () {
>>>
>>>
>>>
>>>        var widthsmall = this.options.widthsmall;
>>>
>>>        var width = this.options.width;
>>>
>>>
>>>
>>>        if (this.options.leftbig != "" && this.options.leftsmall != "") {
>>>
>>>            function bighide() {
>>>
>>>                coupletLeft.style.display = "none";
>>>
>>>                coupletLeftsmall.style.display = "block";
>>>
>>>            }
>>>
>>>
>>>
>>>            function smallhide() {
>>>
>>>                coupletLeftsmall.style.display = "none";
>>>
>>>                coupletLeft.style.display = "block";
>>>
>>>            }
>>>
>>>        }
>>>
>>>
>>>
>>>        if (this.options.rightbig != "" && this.options.rightsmall != "") {
>>>
>>>            function Rbighide() {
>>>
>>>                coupletRight.style.display = "none";
>>>
>>>                coupletRightsmall.style.display = "block";
>>>
>>>            }
>>>
>>>        }
>>>
>>>
>>>
>>>        if (this.NTESPosition()) {
>>>
>>>            if (this.options.leftbig != "" && this.options.leftsmall != ""
>>> && this.options.rightbig != "" && this.options.rightsmall != "") {
>>>
>>>                this.NTESBind(coupletclose, "click", function () {
>>> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>>> coupletLeftsmall.style.display = "none"; });
>>>
>>>                this.NTESBind(coupletclose2, "click", function () {
>>> bighide(); Rbighide(); coupletRightsmall.style.display = "none";
>>> coupletLeftsmall.style.display = "none"; });
>>>
>>>            }
>>>
>>>        }
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Unknown.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://www22.verizon.com
>>>
>>>
>>>
>>> if (floatStyle.match(/Content/)) {
>>>
>>>    var contentDiv = d.getElementById(_b.Preferences.Render.main_content_id
>>> || "content");
>>>
>>>    if (contentDiv == null) {
>>>
>>>        floatStyle = this.Preferences.Render.float_style = 'fixed'
>>>
>>>    }
>>>
>>>    function getRightOfContent() {
>>>
>>>        return contentDiv.offsetWidth + contentDiv.offsetLeft + 1
>>>
>>>    }
>>>
>>>    function fixBackground() {
>>>
>>>        if (_b.Preferences.Render.fix_background) {
>>>
>>>            db.style.backgroundAttachment = "scroll";
>>>
>>>            var margin = null;
>>>
>>>            if (document.defaultView &&
>>> document.defaultView.getComputedStyle) {
>>>
>>>                margin =
>>> parseInt(document.defaultView.getComputedStyle(contentDiv,
>>> null).getPropertyValue("margin-left"), 10)
>>>
>>>            } else {
>>>
>>>                margin = parseInt(contentDiv.currentStyle.marginLeft, 10)
>>>
>>>            }
>>>
>>>            if (isNaN(margin) || margin == 0) {
>>>
>>>                margin = contentDiv.offsetLeft || 0
>>>
>>>            }
>>>
>>>            db.style.backgroundPosition = (Math.floor(contentDiv.scrollWidth
>>> * -0.5) - 2 + margin) + 'px 0'
>>>
>>>        }
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> // getRightOfContent/fixBackground used repeatedly after this.
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Couldn’t find a scenario where this code was hit, but the site is expansive.
>>> Also, the above code is found in at least 2 different scripts across the
>>> site.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://www.jeuxvideo.com
>>>
>>>
>>>
>>> if (typeof getAppNexusMegaTag == 'undefined' || typeof getAppNexusMegaTag !=
>>> 'function') {
>>>
>>>    function getSize1080667() {
>>>
>>>        return '250x250';
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> if (typeof inFIF != "undefined" && inFIF == true) {
>>>
>>>    try {
>>>
>>>        parent.getSize1080667 = getSize1080667;
>>>
>>>    } catch (e) { }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>> ## Scenario
>>>
>>> Ad won’t display.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://msn.foxsports.com
>>>
>>> /* this function is much faster, so if possible we use it. Some IEs are the
>>> only ones I know of that need the idiotic second function, generated by an
>>> if clause.  */ function add32(a, b) {
>>>
>>>    return (a + b) & 0xFFFFFFFF;
>>>
>>> }
>>>
>>>
>>>
>>> if (md5('hello') != '5d41402abc4b2a76b9719d911017c592') {
>>>
>>>    function add32(x, y) {
>>>
>>>        var lsw = (x & 0xFFFF) + (y & 0xFFFF),
>>>
>>>            msw = (x >> 16) + (y >> 16) + (lsw >> 16);
>>>
>>>        return (msw << 16) | (lsw & 0xFFFF);
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Nothing is necessary broken about this, as long as the first add32 functions
>>> properly (today everyone with this code is using the second function). This
>>> is a fairly common MD5 library (do a search for “idiotic second function” to
>>> get an idea, however this was only found once in the dataset).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://iwiw.hu/i/belepes
>>>
>>>
>>>
>>> (function () {
>>>
>>>    if (jQuery.fn.lazyload) {
>>>
>>>        function a() {
>>>
>>>            return typeof f !== "undefined" ? f : (f =
>>> jQuery("body").hasClass("lazyloadimages"))
>>>
>>>        }
>>>
>>>    }
>>>
>>>    jQuery(function () {
>>>
>>>        if (a()) {
>>>
>>>            d.apply(document.body)
>>>
>>>        }
>>>
>>>    })
>>>
>>> })();
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Unknown
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://www.laposte.net
>>>
>>>
>>>
>>> if (!window.$extend) {
>>>
>>>    function $extend(c, a) {
>>>
>>>        for (var b in (a || {})) {
>>>
>>>            c[b] = a[b]
>>>
>>>        } return c
>>>
>>>    }
>>>
>>> }
>>>
>>> // $extend used repeatedly after this
>>>
>>>
>>>
>>> ## Scenario
>>>
>>> Unknown
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://atpworldtour.com
>>>
>>>
>>>
>>> /*
>>>
>>> * Stores hash values for localization.
>>>
>>> * Will need duplicating for each language.
>>>
>>> */
>>>
>>>
>>>
>>> if (typeof registerNS == "undefined") {
>>>
>>>    function registerNS(ns) {
>>>
>>>        var nsParts = ns.split(".");
>>>
>>>        var root = window;
>>>
>>>        for (var i = 0; i < nsParts.length; i++) {
>>>
>>>            if (typeof root[nsParts[i]] == "undefined")
>>>
>>>                root[nsParts[i]] = new Object();
>>>
>>>            root = root[nsParts[i]];
>>>
>>>        }
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> registerNS("atp.utilities");
>>>
>>> // called repeatedly after this.
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Entire site is unusable.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://atwiki.jp
>>>
>>>
>>>
>>> if (typeof AddClipsFlag == "undefined") {
>>>
>>>    var AddClipsFlag = 'addclips';
>>>
>>>    // ...
>>>
>>>    function AddClipsLoad() { /* ... */ }
>>>
>>>    // ...
>>>
>>> }
>>>
>>>
>>>
>>> AddClipsLoad();
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> RSS functionality broken. This appears to be a library of some kind (see
>>> www.addclips.org).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # Library: qTip 1.0:
>>> https://github.com/Craga89/qTip1/blob/master/1.0.0-rc3/jquery.qtip-1.0.0-rc3.js
>>> as seen on Zoompanel.com
>>>
>>>
>>>
>>> if (t.options.hide.when.event == "inactive") {
>>>
>>>    function y(z) {
>>>
>>>
>>>
>>>    }
>>>
>>> } else {
>>>
>>>    // ...
>>>
>>> }
>>>
>>> function x(z) {
>>>
>>>    if (t.options.hide.when.event == "inactive") {
>>>
>>>        y()
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Used on zoompanel.com. Tooltips will never disappear after showing up.
>>>
>>>
>>>
>>>
>>>
>>> # Library: thickbox 3 (http://thickbox.net/), in use on runescape.com and
>>> baixaki.com.br if (!(TB_PrevHTML === "")) {
>>>
>>>    function goPrev(){
>>>
>>>    }
>>>
>>>    $("#TB_prev").click(goPrev);
>>>
>>> }
>>>
>>>
>>>
>>> if (!(TB_NextHTML === "")) {
>>>
>>>    function goNext(){
>>>
>>>    }
>>>
>>>    $("#TB_next").click(goNext);
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>> document.onkeydown = function (e) {
>>>
>>>    if (keycode == 190) { // display previous image
>>>
>>>        if (!(TB_NextHTML == "")) {
>>>
>>>            document.onkeydown = "";
>>>
>>>            goNext();
>>>
>>>        }
>>>
>>>    } else if (keycode == 188) { // display next image
>>>
>>>        if (!(TB_PrevHTML == "")) {
>>>
>>>            document.onkeydown = "";
>>>
>>>            goPrev();
>>>
>>>        }
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Going back/forward with keyboard is broken.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # http://kankan.com
>>>
>>> Snippet
>>>
>>> if (typeof getCookie == 'undefined') {
>>>
>>>    function getCookie(name) {
>>>
>>>
>>>
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>> // ...
>>>
>>>
>>>
>>> if (getCookie('tpar')) {
>>>
>>>    var irStartTime = new Date().getTime();
>>>
>>>    window.attachEvent('onunload', irTimeStat); }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>> Unknown, possibly just for tracking purposes.
>>>
>>>
>>>
>>>
>>>
>>> # Google +1 library (only seen on TMZ.com, possibly this lib is out of date)
>>> try {
>>>
>>>    function h(a) {
>>>
>>>        throw a;
>>>
>>>    }
>>>
>>>    // plus a ton of other decls
>>>
>>> } catch (e) { }
>>>
>>>
>>>
>>> try {
>>>
>>>    h(Error("foo"));
>>>
>>>    // plus a ton of calls to other block scoped functions } catch (e) { }
>>>
>>>
>>>
>>> ## Scenario
>>>
>>>
>>>
>>> Plus one button is broken.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>>    Cheers,
>>    --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Brendan Eich-3
In reply to this post by Mark S. Miller-2
Mark, you cite some issues we need to work through, but opt-in via
pragma syntax beyond "use strict" is not one of them.

What's more, the big-picture claim in your Subject line ("has failed"
especially) is not true. In an overriding sense, 1JS can't fail, because
versioning is an anti-pattern (or at best retrospective, not
prescriptive) on the web. To be more precise, ES6 will fail if it
requires opt-in versioning apart from the new syntax itself. This
applies to "use strict" too, since it has costs (both performance and
semantic changes that double testing while old browsers are in the field).

Now, on the specific JSC bug you cite,
https://bugs.webkit.org/show_bug.cgi?id=27226. This is actually from
2009, filed based on a misunderstanding of ES3 and not on any real-world
web content, and finally marked invalid in February. It is old news. The
comments from February do not prove that "[t]he 1JS experiment has
failed". And JSC design decisions are not authoritative over TC39 as a
whole -- rather, the reverse!.

Anyway, we can certainly make function-in-block ES6 semantics require
"use strict" opt-in, but that will both diminish the use-frequency of
function-in-block with sane and standard semantics, and as Andy Wingo
pointed out in the JSC bug, confuse users with two semantics for the
same syntax.

More in reply to Brian Terlson's thread.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Rick Waldron
In reply to this post by Mark S. Miller-2


On Wednesday, December 26, 2012, Mark S. Miller wrote:
Hi Rick, I cited four "features". 

Unless I misread, 2 of them both concerned block scoped functions and I assumed you were referring to the let[0]=1; which was discussed and consensus on further research towards Luke's resolution was agreed to at the last meeting. I'm actually not sure what new function syntax micro-modes you're referring to, can you clarify?

Rick

 
Blocked scoped functions are simply
the straw that makes the condition of the camel's back more obvious.  

As for the greater good, we're all working for that. We just differ on
which path leads there.  

On Wed, Dec 26, 2012 at 2:25 PM, Rick Waldron <[hidden email]> wrote:
>
>
> On Wednesday, December 26, 2012, Mark S. Miller wrote:
>>
>> Hi Brian, thanks for accumulating this data!
>>
>> Between
>> * this data,
>> * Apple's decision as recorded at
>> <https://bugs.webkit.org/show_bug.cgi?id=27226#c4>,
>> * the new function syntax micro-modes,
>> * and the "let" issues already discussed,
>> I reiterate that we should stop trying to twist the language to
>> somehow shoehorn ES6 features into non-strict mode.
>>
>> For both "function" and "let", when we first discussed trying to
>> retrofit sense into ES6 non-strict mode, we knew that this was
>> speculative, because non-strict mode cannot include web-breaking
>> incompatible changes. This experiment has failed, so we should now
>> return to plan A. Any ES6 features that don't fit into non-strict mode
>> without contortion, including "let" and nested "function", should be
>> available only in strict mode. For new function syntax, if
>> shoe-horning it into non-strict mode requires micro-modes as
>> previously discussed, then we shouldn't. Whatever the complaints about
>> living with one mode distinction, we're certainly not addressing these
>> complaints by introducing more mode distinctions.
>
>
> Proclaiming 1JS has failed just because we've learned that block scoped
> function declarations (arguably an awful and unnecessary idea) is
> counter-productive rhetoric. 1JS is more important than this "feature" and
> like typeof null === "null", I'd rather abandon the one feature for the
> greater good.
>
> Rick
>>
>>
>>
>>
>> On Wed, Dec 26, 2012 at 1:04 PM, Brian Terlson
>> <[hidden email]> wrote:
>> > I have some data on patterns and sites that may break due to the
>> > proposed
>> > change to semantics of function decls in block scope. I am not
>> > advocating
>> > for any changes here but merely dumping some data I’ve gathered. I will
>> > continue gathering data about this breaking change and potentially
>> > others
>> > (eg. let[x] = 1), so any further data you folks are interested in let me
>> > know. I think the January meeting would be a good venue to discuss any
>> > of
>> > this in detail if warranted.
>> >
>> > On December 17th, 2235 sites were crawled and their scripts downloaded.
>> > These scripts were then processed in an attempt to identify likely
>> > breakages
>> > due to the change to the semantics of func decls in block scope. In this
>> > dataset, 4% of the scripts contained a function declaration in block
>> > scope
>> > (mostly inside if and try, although pretty much every node contains a
>> > function somewhere in this dataset). However, most of these scripts use
>> > the
>> > function within the same block and so won’t be broken. 20 sites,
>> > however,
>> > will likely be broken by this change in some way. There is also a chance
>> > that the tool used to identify breakages has missed some code that will
>> > breka.
>> >
>> >
>> >
>> > Below are some examples of code on the web today that will be broken.
>> > For
>> > each I include a snippet of code that is heavily edited in an attempt to
>> > convey the pattern used and the developer intent. I also attempt to
>> > identify
>> > what functionality will actually be broken.
>> >
>> >
>> >
>> > Most of the breakages occur in non-library code, with two exceptions:
>> > qTip
>> > 1.0, and thickbox 3.
>> >
>> >
>> >
>> > # http://ninemsn.com.au
>> >
>> >
>> >
>> > RenderModal = function () {
>> >
>> --
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Dave Herman
In reply to this post by Mark S. Miller-2
On Dec 26, 2012, at 2:30 PM, Mark S. Miller <[hidden email]> wrote:

> Sorry, I'd completely forgotten about those earlier options. I am
> arguing only the latter. Specifically "Any ES6 features that don't fit
> into non-strict mode without contortion, including "let" and nested
> "function", should be available only in strict mode."

Then I'm with Rick: your subject line was pretty inflammatory and not actually what you were arguing. This isn't a debate about 1JS. It's a narrower debate about whether some features should be available only in strict mode. That's not something I feel as strongly about, but here's how I see it:

- Strict mode, while providing some really helpful cleanups of JS, has created introduced serious and unavoidable complexity to programmers. The split has some pretty seriously pervasive differences, in particular the different `this` binding for function calls.

- I believe the least miserable option for programmers to deal with this complexity is just to write code defensively assuming it could be used in strict contexts (e.g., by being concatenated with strict code), and to write all code as strict code. While this is a stick rather than a carrot, at least it's incentive for a good thing: i.e., using strict mode.

- On the other hand, "default is non-strict" is still a huuuuge incentive in the other direction. It's perfectly plausible that for the foreseeable future, many programmers will continue not to use strict mode. If they don't know about strict mode, or don't want to use it for whatever reason, failing to support features like `let` will lead them to use older, worse features in place of better, new ones.

- Andreas has argued before that we should treat that as a feature rather than a bug. He argues that (a) the new features will be carrots to lead people to strict mode; and (b) the incompatibilities between strict and non-strict code are far simpler in total than all the micro-inconsistencies required to shoe-horn the new features into sloppy mode. But my concerns are that for (a) we don't actually know the carrots will be visible or tasty enough for programmers (I took my crystal ball to the pawn shop years ago), and for (b) the big-but-obvious inconsistencies will be universally, unavoidably tripped over. I'm just worried it's choosing "slap the developer in the face" instead of doing the work to iron out an imperfect but less obnoxious back-porting story.

So I guess I'd like to sit back a bit and hear others' opinions about this. But let's be clear that we're only talking about excluding some new features from sloppy mode, *not* about the ES6 opt-in.

Dave

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Mark S. Miller-2
In reply to this post by Brendan Eich-3
On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich <[hidden email]> wrote:
> Mark, you cite some issues we need to work through, but opt-in via pragma
> syntax beyond "use strict" is not one of them.

Sorry for the confusion. As I just clarified in my response to Dave, I
am not suggesting any of those previous MIME type or additional pragma
ideas. I am just suggesting that we stop twisting the language to try
to fit ES6 features into non-strict mode when these don't fit well.


> What's more, the big-picture claim in your Subject line ("has failed"
> especially) is not true. In an overriding sense, 1JS can't fail, because
> versioning is an anti-pattern (or at best retrospective, not prescriptive)
> on the web. To be more precise, ES6 will fail if it requires opt-in
> versioning apart from the new syntax itself.

I am not suggesting any new opt-in beyond what we've already got. I am
suggesting that we use that opt-in, rather than contort the language
for the sake of non-strict mode. We all know that the non-strict mode
of JavaScript can never grow into a decent language. As you've long
said about the arguments object, let's stop polishing this turd.


> This applies to "use strict"
> too, since it has costs (both performance and semantic changes that double
> testing while old browsers are in the field).

I thought we'd settled the performance issue. I'm surprised you're
still raising it.

The purpose of testing is to alert you to places in your code where
bugs may reside. Even if you never plan to run your code in strict
mode, you should still test in strict mode, since anything that fails
in strict mode is likely enough a bug in your code that you should
investigate.


>
> Now, on the specific JSC bug you cite,
> https://bugs.webkit.org/show_bug.cgi?id=27226. This is actually from 2009,
> filed based on a misunderstanding of ES3 and not on any real-world web
> content, and finally marked invalid in February. It is old news. The
> comments from February do not prove that "[t]he 1JS experiment has failed".

I was unaware of the history, thanks. I withdraw that bullet point. I
acknowledge that my case is substantially weaker without it.


> And JSC design decisions are not authoritative over TC39 as a whole --
> rather, the reverse!.

We all know that this issue isn't so unidirectional. If TC39 mandates
something and the browser makers decide to do something else, we all
have a problem. The pressure to avoid these problems cuts both ways.


> Anyway, we can certainly make function-in-block ES6 semantics require "use
> strict" opt-in, but that will both diminish the use-frequency of
> function-in-block with sane and standard semantics,

Since only strict mode provides sane and standard semantics anyway... ;)

> and as Andy Wingo
> pointed out in the JSC bug, confuse users with two semantics for the same
> syntax.

We've already got that. To avoid confusion, "use strict".


>
> More in reply to Brian Terlson's thread.
>
> /be
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Mark S. Miller-2
In reply to this post by Dave Herman
On Wed, Dec 26, 2012 at 2:58 PM, David Herman <[hidden email]> wrote:

> On Dec 26, 2012, at 2:30 PM, Mark S. Miller <[hidden email]> wrote:
>
>> Sorry, I'd completely forgotten about those earlier options. I am
>> arguing only the latter. Specifically "Any ES6 features that don't fit
>> into non-strict mode without contortion, including "let" and nested
>> "function", should be available only in strict mode."
>
> Then I'm with Rick: your subject line was pretty inflammatory and not actually
> what you were arguing. This isn't a debate about 1JS. It's a narrower debate
> about whether some features should be available only in strict mode.

Just to clarify why I used that admittedly inflammatory title: When I
had previously argued this point, specifically regarding "let",
someone (I thought it was you) cited "1JS" as a reason to try bringing
such ES6 features to non-strict (sloppy) mode. If 1JS implies that we
should do so, then I reject the 1JS doctrine. If I misunderstood, then
I withdraw putting this in terms of 1JS.

I think you did coin "1JS". What do you mean by it? Does it bear on
the present issue or not?

[...]

> So I guess I'd like to sit back a bit and hear others' opinions about this.
> But let's be clear that we're only talking about excluding some new features
> from sloppy mode, *not* about the ES6 opt-in.

Agreed.


>
> Dave
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Brandon Benvie
I must admit, I'm a bit confused. My understanding of 1JS was that it meant no new modes or pragmas. That seems to have little bearing on whether a feature is restricted to strict mode or not, because that ship has already sailed and the cost is sunk. 

Aside from 1JS is, I think, a different discussion about what belongs in strict mode, and what the cost is of putting a feature in strict mode vs. making it available in normal mode. Generally, the cost of making something available in normal mode is greater compatibility hurdles (as we see with function decls in block scope), while the cost of putting things in strict mode is in increasing the gap in semantics between code that is otherwise identical besides the leading "use strict" pragma.

Perhaps the second part is part of the 1JS discussion, but I think the discussion already seen today indicates there is two separate issues, one which is settled and agreed upon and one which is ongoing.


On Wed, Dec 26, 2012 at 6:35 PM, Mark S. Miller <[hidden email]> wrote:
On Wed, Dec 26, 2012 at 2:58 PM, David Herman <[hidden email]> wrote:
> On Dec 26, 2012, at 2:30 PM, Mark S. Miller <[hidden email]> wrote:
>
>> Sorry, I'd completely forgotten about those earlier options. I am
>> arguing only the latter. Specifically "Any ES6 features that don't fit
>> into non-strict mode without contortion, including "let" and nested
>> "function", should be available only in strict mode."
>
> Then I'm with Rick: your subject line was pretty inflammatory and not actually
> what you were arguing. This isn't a debate about 1JS. It's a narrower debate
> about whether some features should be available only in strict mode.

Just to clarify why I used that admittedly inflammatory title: When I
had previously argued this point, specifically regarding "let",
someone (I thought it was you) cited "1JS" as a reason to try bringing
such ES6 features to non-strict (sloppy) mode. If 1JS implies that we
should do so, then I reject the 1JS doctrine. If I misunderstood, then
I withdraw putting this in terms of 1JS.

I think you did coin "1JS". What do you mean by it? Does it bear on
the present issue or not?

[...]

> So I guess I'd like to sit back a bit and hear others' opinions about this.
> But let's be clear that we're only talking about excluding some new features
> from sloppy mode, *not* about the ES6 opt-in.

Agreed.


>
> Dave
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Mark S. Miller-2
On Wed, Dec 26, 2012 at 3:53 PM, Brandon Benvie
<[hidden email]> wrote:

> I must admit, I'm a bit confused. My understanding of 1JS was that it meant
> no new modes or pragmas. That seems to have little bearing on whether a
> feature is restricted to strict mode or not, because that ship has already
> sailed and the cost is sunk.
>
> Aside from 1JS is, I think, a different discussion about what belongs in
> strict mode, and what the cost is of putting a feature in strict mode vs.
> making it available in normal mode. Generally, the cost of making something
> available in normal mode is greater compatibility hurdles (as we see with
> function decls in block scope), while the cost of putting things in strict
> mode is in increasing the gap in semantics between code that is otherwise
> identical besides the leading "use strict" pragma.
>
> Perhaps the second part is part of the 1JS discussion, but I think the
> discussion already seen today indicates there is two separate issues, one
> which is settled and agreed upon and one which is ongoing.

Agreed. I had not meant to imply that I was reopening the earlier
issue. Perhaps I had misunderstood the meaning of 1JS. But I don't
much care what we call it. I just hope we can stop sacrificing other
values for the sake of sloppy mode.


>
>
> On Wed, Dec 26, 2012 at 6:35 PM, Mark S. Miller <[hidden email]> wrote:
>>
>> On Wed, Dec 26, 2012 at 2:58 PM, David Herman <[hidden email]> wrote:
>> > On Dec 26, 2012, at 2:30 PM, Mark S. Miller <[hidden email]> wrote:
>> >
>> >> Sorry, I'd completely forgotten about those earlier options. I am
>> >> arguing only the latter. Specifically "Any ES6 features that don't fit
>> >> into non-strict mode without contortion, including "let" and nested
>> >> "function", should be available only in strict mode."
>> >
>> > Then I'm with Rick: your subject line was pretty inflammatory and not
>> > actually
>> > what you were arguing. This isn't a debate about 1JS. It's a narrower
>> > debate
>> > about whether some features should be available only in strict mode.
>>
>> Just to clarify why I used that admittedly inflammatory title: When I
>> had previously argued this point, specifically regarding "let",
>> someone (I thought it was you) cited "1JS" as a reason to try bringing
>> such ES6 features to non-strict (sloppy) mode. If 1JS implies that we
>> should do so, then I reject the 1JS doctrine. If I misunderstood, then
>> I withdraw putting this in terms of 1JS.
>>
>> I think you did coin "1JS". What do you mean by it? Does it bear on
>> the present issue or not?
>>
>> [...]
>>
>> > So I guess I'd like to sit back a bit and hear others' opinions about
>> > this.
>> > But let's be clear that we're only talking about excluding some new
>> > features
>> > from sloppy mode, *not* about the ES6 opt-in.
>>
>> Agreed.
>>
>>
>> >
>> > Dave
>> >
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Norbert Lindenberg-3
In reply to this post by Mark S. Miller-2

On Dec 26, 2012, at 15:35 , Mark S. Miller wrote:

> On Wed, Dec 26, 2012 at 2:58 PM, David Herman <[hidden email]> wrote:
>> On Dec 26, 2012, at 2:30 PM, Mark S. Miller <[hidden email]> wrote:
>>
>>> Sorry, I'd completely forgotten about those earlier options. I am
>>> arguing only the latter. Specifically "Any ES6 features that don't fit
>>> into non-strict mode without contortion, including "let" and nested
>>> "function", should be available only in strict mode."
>>
>> Then I'm with Rick: your subject line was pretty inflammatory and not actually
>> what you were arguing. This isn't a debate about 1JS. It's a narrower debate
>> about whether some features should be available only in strict mode.
>
> Just to clarify why I used that admittedly inflammatory title: When I
> had previously argued this point, specifically regarding "let",
> someone (I thought it was you) cited "1JS" as a reason to try bringing
> such ES6 features to non-strict (sloppy) mode. If 1JS implies that we
> should do so, then I reject the 1JS doctrine. If I misunderstood, then
> I withdraw putting this in terms of 1JS.
>
> I think you did coin "1JS". What do you mean by it? Does it bear on
> the present issue or not?

Dave's original email:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html

For TC39 members, there's a nice presentation in the archive: Ecma/TC39/2012/005.

The basic idea was that, instead of versioning through MIME types or pragmas, programs would opt into ES6 semantics by using modules. There was nothing about making all ES6 features available in all contexts.

Norbert


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Dave Herman
In reply to this post by Mark S. Miller-2
On Dec 26, 2012, at 3:35 PM, Mark S. Miller <[hidden email]> wrote:

> I think you did coin "1JS". What do you mean by it? Does it bear on
> the present issue or not?

I coined the "just one JavaScript" here:

    https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html

And it got shortened to 1JS not long after (maybe in the same thread?). The key point was no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for new semantics" section), you'll see that I actually proposed that anything that can't be made to work in legacy code can be left out of sloppy mode.

Dave

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Brendan Eich-3
In reply to this post by Mark S. Miller-2
Mark S. Miller wrote:
> On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich<[hidden email]>  wrote:
>> Mark, you cite some issues we need to work through, but opt-in via pragma
>> syntax beyond "use strict" is not one of them.
>
> Sorry for the confusion. As I just clarified in my response to Dave, I
> am not suggesting any of those previous MIME type or additional pragma
> ideas. I am just suggesting that we stop twisting the language to try
> to fit ES6 features into non-strict mode when these don't fit well.

Your subject was a declarative sentence, past tense, not a suggestion!
It also meant other than what you clarified.

Ok, I don't mean to vent -- moving right along:

>> What's more, the big-picture claim in your Subject line ("has failed"
>> especially) is not true. In an overriding sense, 1JS can't fail, because
>> versioning is an anti-pattern (or at best retrospective, not prescriptive)
>> on the web. To be more precise, ES6 will fail if it requires opt-in
>> versioning apart from the new syntax itself.
>
> I am not suggesting any new opt-in beyond what we've already got. I am
> suggesting that we use that opt-in, rather than contort the language
> for the sake of non-strict mode. We all know that the non-strict mode
> of JavaScript can never grow into a decent language. As you've long
> said about the arguments object, let's stop polishing this turd.

But it's not the same turd. Rest parameters combined with destructuring
and default parameters can do more than arguments could do, and
crucially do so via new syntax. There's no comparison to function in
block, which syntax already exists in the de-facto standard, whose
meaning ES6 proposes to change.

Let's move away from feces metaphors :-|.

The major issue I see outstanding between us is that the economics of
strict mode as faced by most developers must be considered, on top of
the desirability of the feature that doesn't fit in sloppy mode.

This is a human factors problem in part. We should do quantitative
studies. I just asked in re: Brian's head post whether his crawl checked
for "use strict" usage. Another thing we could try: for the 4% of
scripts used by the 2235 sites crawled that use funciton-in-block, how
many can "use strict" without any revision?

The economics of strict mode is subject to pedagogy, better
optimizations for strict code over time, and the death of pre-ES5-strict
browsers over time, too. So again I'm not beating up on strict mode. But
I do think we must look at the thing in the field, including its human
factors, and not just say "use strict" always, be happy. It's not always
an option in large projects or even small ones using libraries that
aren't strict-ready. More below.


>> This applies to "use strict"
>> too, since it has costs (both performance and semantic changes that double
>> testing while old browsers are in the field).
>
> I thought we'd settled the performance issue. I'm surprised you're
> still raising it.

It's not quite superstition. Look at the strict vs. non-strict
differences in the charts for these three:

http://jsperf.com/calling-into-strict
http://jsperf.com/use-strict-vs-array/2
http://jsperf.com/use-strict-vs-array/3

In theory, apart from freakish cases involving arguments objects and
parameter aliasing, strict mode should not be a performance penalty and
could even help. In practice we aren't there yet -- and developers know
this.

> The purpose of testing is to alert you to places in your code where
> bugs may reside. Even if you never plan to run your code in strict
> mode, you should still test in strict mode, since anything that fails
> in strict mode is likely enough a bug in your code that you should
> investigate.

You don't need to tell me!

The problems is the added burden and the inevitable failure of real
developers to take it on with the same diligence they use on one-mode JS
-- which may be less diligence than you would like, but hold that equal!
The testing burden has gone up.

I'm describing, not prescribing. Old pre-strict browsers will die off,
we'll be in a better place. I like strict mode in general and won't
quibble about a few corners here. But the problem isn't my opinion of it
or yours. The problem is that strict mode has meant more to go wrong,
more to test, and some performance faults.

>> Now, on the specific JSC bug you cite,
>> https://bugs.webkit.org/show_bug.cgi?id=27226. This is actually from 2009,
>> filed based on a misunderstanding of ES3 and not on any real-world web
>> content, and finally marked invalid in February. It is old news. The
>> comments from February do not prove that "[t]he 1JS experiment has failed".
>
> I was unaware of the history, thanks. I withdraw that bullet point. I
> acknowledge that my case is substantially weaker without it.

Ok, thanks.

>> And JSC design decisions are not authoritative over TC39 as a whole --
>> rather, the reverse!.
>
> We all know that this issue isn't so unidirectional. If TC39 mandates
> something and the browser makers decide to do something else, we all
> have a problem. The pressure to avoid these problems cuts both ways.

And how! We've already heard some feedback on temporal dead zones from
one TC39 implementor-rep at the September meeting. I never said
implementor feedback doesn't count, though. Only that the
authority-arrow runs the other way from what your bullet point suggested.

It's pure mischief for implementors to "vote" outside of TC39 by making
random deviations from draft-ES6 on purpose and then asserting precedent
or authority.

I know you didn't endorse that but your citing this bug under the
inflammatory subject was going in that direction.

>> Anyway, we can certainly make function-in-block ES6 semantics require "use
>> strict" opt-in, but that will both diminish the use-frequency of
>> function-in-block with sane and standard semantics,
>
> Since only strict mode provides sane and standard semantics anyway... ;)
>
>> and as Andy Wingo
>> pointed out in the JSC bug, confuse users with two semantics for the same
>> syntax.
>
> We've already got that. To avoid confusion, "use strict".

That's a prospective, prescriptive, pedagogical approach. It will help
over time, but right now, not so much. Real developers face real code,
most of it non-strict. They can't always afford to make it all strict.
They therefore face the confusing schism in function-in-block semantics
that Andy cited.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Brandon Benvie
As an aside, ES itself can't self-host its own builtins in strict mode because of the (two of the very few) semantic differences that exist between strict mode and non-strict mode: non-strict thrower properties (which I've come to consider an annoying blight that punishes developers in order to influence implementers) and strict this-mode differences. Every semantic difference you mandate furthers this gap.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: The 1JS experiment has failed. Let's return to plan A.

Brandon Benvie
Er I meant ThrowTypeError.


On Wed, Dec 26, 2012 at 8:52 PM, Brandon Benvie <[hidden email]> wrote:
As an aside, ES itself can't self-host its own builtins in strict mode because of the (two of the very few) semantic differences that exist between strict mode and non-strict mode: non-strict thrower properties (which I've come to consider an annoying blight that punishes developers in order to influence implementers) and strict this-mode differences. Every semantic difference you mandate furthers this gap.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode

Brendan Eich-3
In reply to this post by Dave Herman
David Herman wrote:

> On Dec 26, 2012, at 3:35 PM, Mark S. Miller<[hidden email]>  wrote:
>
>> I think you did coin "1JS". What do you mean by it? Does it bear on
>> the present issue or not?
>
> I coined the "just one JavaScript" here:
>
>      https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
>
> And it got shortened to 1JS not long after (maybe in the same thread?). The key point was no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for new semantics" section), you'll see that I actually proposed that anything that can't be made to work in legacy code can be left out of sloppy mode.

Not arguing in reply, rather taking this opportunity to
expound/recollect a bit, bear with me!

The lingering, not-quite-resolved issue I see Mark raising depends on
the exact definition of "can be left out of sloppy mode" or (should that
be reworded?) "can be included in sloppy mode but only with some
incompatibility or contortion [but not binding-dependent parsing]".

Long before 1JS, in prototyping ES4 features in SpiderMonkey "JS1.7" and
up (which ended up in Rhino as well), and inspired by Opera's array
destructuring, we started adding new features without requiring opt-in
version selection. The new syntax was enough. This covered
destructuring, and it turned off sloppy-mode craziness that was hard to
implement or teach (e.g., destructuring parameters made duplicate formal
parameters an error in JS1.7+, prefiguring strict mode).

We ran into problems with 'let' and 'yield' used as identifiers, and
lacking function* syntax for generators, we did require opt-in by
version= for those two but nothing else.

With 1JS as you proposed it (and if my memory serves), 'module' was
enough to opt into new syntax (and it also implied "use strict"), but
there was room for other new syntax outside of module (and outside of
"use strict") to be its own opt-in.

Since then I think TC39 has moved along toward enabling opt-in by new
syntax where it's clean. New function head syntax (rest, default,
destructuring parameters; function* for generators, which reserves yield
in the body), at least.

We knew 'let' could be a problem. Also we knew function-in-block was a
breaking change. As you noted, and Brandon nicely separated in his reply
as well, we can certainly require "use strict" to have function-in-block
semantics. We may be left with no other choice.

Just to recap the last TC39 meeting, we agreed to try reserving 'let' in
sloppy mode. Mark wasn't happy about that, not so much because of
incompatibility due to let[x] = y; changing meaning, more -- this is my
interpretation, Mark should correct me -- because he wanted to promote
strict mode, not elaborate sloppy mode ("don't polish a turd") , and
keep each mode simpler by most measures.

I do not think the problems we anticipated with function-in-block and
'let' mean we retreat to requiring "use strict" for all new syntax
outside of implciitly-strict modules. This is my punch-line:
function-head new syntax in sloppy mode, including stricter error
checking (e.g. for duplicate formals), should stand. It is better for
the users, and probably even for the spec, to make such new syntax its
own opt-in.

So, case by case:

* arrow function syntax (which does not imply "use strict" in body prologue)
* class
* const
* default parameters
* destructuring
* rest parameters
* generators (function*, yield in function* body)
* comprehensions
* generator expressions
* module

all seem to work in 1JS via the "new syntax is its own opt-in" rule,
including any stricter/saner semantic checking.

I left out 'let' and function-in-block. Let's set those aside for a moment.

Anyone disagree that the bulleted syntactic extensions listed above
should be their own opt-in, and think instead that some or others or all
should appear only to strict code? (Mark, here's your chance! ;-)

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

Mark S. Miller-2
In reply to this post by Dave Herman
On Wed, Dec 26, 2012 at 4:59 PM, David Herman <[hidden email]> wrote:

> On Dec 26, 2012, at 3:35 PM, Mark S. Miller <[hidden email]> wrote:
>
>> I think you did coin "1JS". What do you mean by it? Does it bear on
>> the present issue or not?
>
> I coined the "just one JavaScript" here:
>
>     https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
>
> And it got shortened to 1JS not long after (maybe in the same thread?). The key point was no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for new semantics" section), you'll see that I actually proposed that anything that can't be made to work in legacy code can be left out of sloppy mode.

Excellent. Thanks for the clarification. Sorry again for the confusion.


>
> Dave
>



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: excluding features from sloppy mode

Mark S. Miller-2
In reply to this post by Brendan Eich-3
On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich <[hidden email]> wrote:

> David Herman wrote:
>>
>> On Dec 26, 2012, at 3:35 PM, Mark S. Miller<[hidden email]>  wrote:
>>
>>> I think you did coin "1JS". What do you mean by it? Does it bear on
>>> the present issue or not?
>>
>>
>> I coined the "just one JavaScript" here:
>>
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
>>
>> And it got shortened to 1JS not long after (maybe in the same thread?).
>> The key point was no (new) opt-in for ES6. If you read the message (see the
>> "Modules as the opt-in for new semantics" section), you'll see that I
>> actually proposed that anything that can't be made to work in legacy code
>> can be left out of sloppy mode.
>
>
> Not arguing in reply, rather taking this opportunity to expound/recollect a
> bit, bear with me!
>
> The lingering, not-quite-resolved issue I see Mark raising depends on the
> exact definition of "can be left out of sloppy mode" or (should that be
> reworded?) "can be included in sloppy mode but only with some
> incompatibility or contortion [but not binding-dependent parsing]".
>
> Long before 1JS, in prototyping ES4 features in SpiderMonkey "JS1.7" and up
> (which ended up in Rhino as well), and inspired by Opera's array
> destructuring, we started adding new features without requiring opt-in
> version selection. The new syntax was enough. This covered destructuring,
> and it turned off sloppy-mode craziness that was hard to implement or teach
> (e.g., destructuring parameters made duplicate formal parameters an error in
> JS1.7+, prefiguring strict mode).
>
> We ran into problems with 'let' and 'yield' used as identifiers, and lacking
> function* syntax for generators, we did require opt-in by version= for those
> two but nothing else.
>
> With 1JS as you proposed it (and if my memory serves), 'module' was enough
> to opt into new syntax (and it also implied "use strict"), but there was
> room for other new syntax outside of module (and outside of "use strict") to
> be its own opt-in.
>
> Since then I think TC39 has moved along toward enabling opt-in by new syntax
> where it's clean. New function head syntax (rest, default, destructuring
> parameters; function* for generators, which reserves yield in the body), at
> least.
>
> We knew 'let' could be a problem. Also we knew function-in-block was a
> breaking change. As you noted, and Brandon nicely separated in his reply as
> well, we can certainly require "use strict" to have function-in-block
> semantics. We may be left with no other choice.
>
> Just to recap the last TC39 meeting, we agreed to try reserving 'let' in
> sloppy mode. Mark wasn't happy about that, not so much because of
> incompatibility due to let[x] = y; changing meaning, more -- this is my
> interpretation, Mark should correct me -- because he wanted to promote
> strict mode, not elaborate sloppy mode ("don't polish a turd") , and keep
> each mode simpler by most measures.

You got it. I don't want to see the overall language become more
complex just so we can provide new features to sloppy mode.

I think the core of our disagreement is this:

Until ES3 browsers become insignificant, there is the additional
testing burden you mention. This is a transitional issue, but I agree
it is a significant one. But it will be years before ES6 rolls out in
browsers. Old browser versions fade out much faster than they used to
(due mainly to more aggressive auto update). So I do not expect
significant practical overlap between ES6 browsers and ES3 browsers.

Superstition aside, and once pre-ES5 browsers are not significant, the
only purpose of sloppy mode is for old code that must be kept running
without active maintenance. For any code being actively maintained, it
should move into strict mode. Sloppy mode will become a relic only for
code no one touches.


>
> I do not think the problems we anticipated with function-in-block and 'let'
> mean we retreat to requiring "use strict" for all new syntax outside of
> implciitly-strict modules. This is my punch-line: function-head new syntax
> in sloppy mode, including stricter error checking (e.g. for duplicate
> formals), should stand. It is better for the users, and probably even for
> the spec, to make such new syntax its own opt-in.
>
> So, case by case:
>
> * arrow function syntax (which does not imply "use strict" in body prologue)
> * class
> * const
> * default parameters
> * destructuring
> * rest parameters
> * generators (function*, yield in function* body)
> * comprehensions
> * generator expressions
> * module
>
> all seem to work in 1JS via the "new syntax is its own opt-in" rule,
> including any stricter/saner semantic checking.
>
> I left out 'let' and function-in-block. Let's set those aside for a moment.
>
> Anyone disagree that the bulleted syntactic extensions listed above should
> be their own opt-in, and think instead that some or others or all should
> appear only to strict code? (Mark, here's your chance! ;-)

I would apply one simple test to all of these: Does it make the
overall language simpler, and strict mode no more complex, to make
these available in sloppy mode as well? Most of these pass this test.
Once we started talking about micro-modes for new function syntaxes,
it became clear that these do not. So for these, if they cannot be
provided to sloppy mode without micro-modes, they shouldn't be
provided to sloppy mode at all.



>
> /be



--
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234 ... 9