On Sep 2, 2015, at 4:58 PM, Brendan Eich wrote: > saam barati wrote: >> Thanks. Reading now. >> >> I'm clearly bad at email :/ > > Naw, this stuff is always harder to find than it should be. > > I was there, I just re-read and re-remembered. I do not agree with Allen that > some tiny needle was uniquely threaded. Rather, an aesthetic preference for > the new ES6 binding forms to have a lexical contour of their own when used at > top level prevailed. This leads to problems, not all of which were known at > the time -- but some problems were noted.
I didn't mean to imply that it was the only threading of the requirement needles, but it was the one we could reach consensus on. It isn't even my favorite ( I would of preferred something similar to Saam's suggestion) but consensus on something was necessary in order to have publish a standard. > > The REPL problem, where let z=z; makes a poison pill, could be coped with by > ad-hoc REPL deviations from the spec -- at some cost. Let's set it aside. > > The one-time change to a reference, from global object to lexical shadowing > binding, is a serious flaw. Yes, it could happen due to explicit scope > nesting, but the global scope is apparently uniform. There's no explicit > delimiter. > > The implementors seem to be rebelling but I'm not trying to stir up trouble. > It would help if V8 did support let, etc. in sloppy mode. Then we might see > open rebellion among two or more implementors. > > When it comes to aesthetics vs. implementability and usability, we have to > throw aesthetics under the bus. This is JavaScript, after all! :-P Ok, > seriously, we did not actually make anything prettier. The top level is > hopeless. All we did was leave a couple of hazards for implementors and users > in ES6. > > Making the new binding forms create global properties (or throw trying), as I > implemented long ago for let in ES4 in SpiderMonkey, is ugly, but it does not > introduce any net-new hazards. But it introduces many inconsistencies between the semantics of let/const/class at the global level and their handling within nested scopes. Also, it perpetuates the the pollution of the windows object with program state, the avoidance of which was one of the requirements that was being promoted. The way I see it, when none of the alternatives are good ones, it is TC39's job to choose (as long as the choice is implementable). In such cases implementations should just follow the spec, unless there is a truly new alternative that T39 didn't consider or other new information. It really isn't very usefully to revisit a difficult decision without any new information to add to the discussion. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
