On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> If using an uninitialized let binding is an error, then hoisting is >> pointless except to make the statements between start of block and >> the >> let declaration a dead zone for the binding name. This fits the >> ancient, weak but not entirely worthless post-hoc rationale for var >> hoisting (to avoid confusion among novice or inexperienced >> programmers >> by making many scopes, each implicitly opened by var), but it's not >> particularly useful. > > This was our agreement from the ES4 days. It's very useful, in that > it allows mutually recursive lambdas.
For function bindings, yes, of course -- but we were talking about let bindings (I thought). For let (there is no 'let function') bindings, how? Could you give an example? >> What's more, as discussed here and in TC39, repeated let declarations >> for the same binding name within the same block should be allowed. > > You can't do that in ES-Harmony. There is no way to tell if the two > let declarations have the same type. There has to be a way to answer the question "are these two terms the same type" at run-time. > For orthogonality you'd also need to allow multiple const > declarations within the same scope, and I just don't want to go there. I don't agree -- const and let are different keywords, they obviously differ in read-only vs. writable binding. They could differ otherwise. >> Anything else is user- and refactoring-hostile. So the non-initial >> let >> declarations for a given name in the same block would be ignored. > > This is loaded language, but I can't tell how requiring there to be > a unique point of definition for a const or let is user-hostile. My words were about let, not const. If let is the new var, then you either accept that re-declaration in the same block (usually function body) of the same name via var is common for good reason, and allow let to be used instead; or you raise the migration tax. I do not mean to over-load the language, but we've seen a lot of code that redeclares using var (e.g. for (var i...) in adjacent for loops). We tried making a strict warning (error console spew) for redeclarations of same kind (var vs. var) four years ago (IIRC -- Firefox 1 betas) and felt the heat from developers. We fell back on mixed var vs. function (const vs. anything is an error of course). People on this list have argued similarly based on refactoring and var hoisting. It may be that the migration tax must rise here, but I'd like to know why type annotations can't be equated at runtime. /be _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
