On Monday, October 22, 2012 at 1:04 AM, Domenic Denicola wrote:
> Thanks for your help Rick! I've corrected a few, but wasn't sure about some > others. Let me know if I'm missing something in the following: > > From: Rick Waldron [mailto:[email protected]] > Sent: Sunday, October 21, 2012 17:07 > > > nit: The comment itself says "// error! used a `let` before declaration.", > > might be nice to highlight that the error will occur until the let is > > assigned, ie. I can initialize it, but reads will throw until it's assigned. > > If I'm understanding you correctly, you're saying that this should throw? > > let x; > assert(x === undefined); // error! Use of `x` before it is assigned. > > yes, any read access will throw before assignment. > > I was under the impression the temporal dead zone was about > use-before-definition, not use-before-assignment. There is no deadzone in the former, it's use-before-assignment > (For const they are the same, since the "Static Semantics: Early Errors" note > on page 125 of the spec gives a Syntax Error if the Initialiser is omitted > from the LexicalBinding.) That is: > > "A let and const declarations define variables that are scoped to the running > execution context’s LexicalEnvironment. The variables are created when their > containing Lexical Environment is instantiated but may not be accessed in any > way until the variable’s LexicalBinding is evaluated. A variable defined by a > LexicalBinding with an Initialiser is assigned the value of its Initialiser’s > AssignmentExpression when the LexicalBinding is evaluated, not when the > variable is created. If a LexicalBinding in a let declaration does not have > an an Initialiser the variable is assigned the value undefined when the > LexicalBinding is evaluated." > > This implies to me that the first line above evaluates the LexicalBinding, > assigning the variable the value undefined; since the LexicalBinding is > evaluated, the "may not be accessed" clause no longer applies, and no error > should occur. I'm not sure the full temporal deadzone semantics are even in a draft yet (like lots of things) > > > > Not sure of the number, but there is a slide titled "Block Scoping" with > > this: > > > if (Math.random() > 0.5) { > > function go() { > > console.log("gone!"); > > } > > ... > > } > > assert(typeof go === "undefined"); > > > > > > I'm not sure I get what this one is trying to illustrate, because "go" will > > always be initialized, regardless of the condition > > I believe this is not true. The current semantics for block-scoped functions > bind them to the block, not to the surrounding function. (That is, a > FunctionDeclaration creates an entry into LexicallyDeclaredNames, not into > VarDeclaredNames.) > Even in ES5, this behavior is unspecified: see the "NOTE" under the > "Semantics" heading under section 12 of ES5.1, where it notes that even > though Statement does not include FunctionDeclaration, implementations often > allow it, with "significant and irreconcilable variations." (So, I don't > think "go" will always be initialized in all browsers. For example, in IE10 > strict mode the above code is a SyntaxError.) It also says that "Future > editions of ECMAScript may define alternative portable means for declaring > functions in a Statement context." > > And indeed, in ES6 the Declaration grammar production is introduced as a > sibling to Statement under Block. It includes LexicalDeclaration and > FunctionDeclaration; VariableStatements are left under Statement. And the > Block Declaration Instantiation algorithm (10.5.4) includes both > LexicalDeclarations and FunctionDeclarations, i.e. FunctionDeclarations are > added to the block's Declarative Environment Record instead of to the > environment record of the containing function. > > > new Set(...document.body.children); > > > is a Syntax Error, use: > > > new Set([ ...document.body.children ]); > > > Same for: > > new Set(...array) > > Math.max(...array); > > Math.max(0, ...array, 5, ...array2); > > new Date(...dateFields); > > array.push(...array2); > > > > > I don't think any of these is a syntax error, since spread works for function > calls/constructs too. See http://tc39wiki.calculist.org/es6/spread/ or > section 11.2.5 of the draft spec wherein the expanded runtime semantics for > ArgumentListEvaluation are given (in particular ArgumentList: > ...AssignmentExpression and ArgumentList: ArgumentList, > ...AssignmentExpression). However, you are right that the sets should be > constructed that way, since the Set constructor accepts an iterable and not > varargs. Much appreciated! Not according to SpiderMonkey, so someone has a bug. > > Also, I just realized that in rearranging my slides I used spread before > discussing it -_-. Will need to fix. Maybe "rest and spread" are more comfort > than cowpath-paving... > > > Weak Sets aren't specified yet. Might be wise to omit that? > > Yeah, probably a good place to trim the fat. They are harmonious though, > right? Since they're necessary for revocable proxies. They are, but no like I said, no spec yet > > > One of WeakMap's best use cases is private data... > > > ... This way any number of methods, both on C's prototype or class-side > > functions, as long as they are defined in the same scope that "priv" is > > bound to, can access the private cache in "priv". This beats leaky plain > > object abstractions for a serious win :) > > The problem I've always had with this is that using weak maps for objects you > control is silly, when you could just use symbols. Indeed I illustrate the > symbol vs. weak map question in my "Symbols Again" slide. Weak maps are more > correct for objects you don't control though, due to the possibility of > extension-prevented objects (as I plan to point out when that slide comes > up). But for the simple private data use case, symbols are great. I was > really glad Brendan reminded me that the values are also held weakly, since > otherwise weak maps just reduce to a more-cumbersome, but safer, version of > symbols. It's not silly when you don't have symbols available. Another better example is using a DOM node as a key to associate data > > Again, thanks for your help, and see you tomorrow!
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
