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 <waldron.r...@gmail.com> > 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 > >> <brian.terl...@microsoft.com> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
