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

Rick Waldron waldron.rick at gmail.com
Wed Dec 26 14:58:18 PST 2012


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.rick at 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.Terlson at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121226/dfceecf6/attachment.html>


More information about the es-discuss mailing list