<br><br><div class="gmail_quote">On Mon, Oct 22, 2012 at 12:43 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Mon, Oct 22, 2012 at 5:27 AM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">

<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
    <div><br></div>
     
    <p style="color:#a0a0a8">On Monday, October 22, 2012 at 1:04 AM, Domenic Denicola wrote:</p>
    <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
        <div><div><div>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:</div><div><br></div><div>From: Rick Waldron [mailto:<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>] </div>


<div>Sent: Sunday, October 21, 2012 17:07</div><div><br></div><blockquote type="cite"><div>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.</div>


</blockquote><div><br></div><div>If I'm understanding you correctly, you're saying that this should throw?</div><div><br></div><div>let x;</div><div>assert(x === undefined); // error! Use of `x` before it is assigned.</div>


</div></div></blockquote></div><div>yes, any read access will throw before assignment.†</div></blockquote><div><br></div></div><div>We are planning to revisit this once we get some performance measurements of the cost of the current semantics. But Rick's position contradicts my understanding of what the current semantics is. My understanding is the same as Domenic's original: the let declaration initializes x (in this case to undefined), so the following use is outside the temporal dead zone and succeeds.</div>

</div></div></blockquote><div><br></div><div><br></div><div>My response was based on a re-reviewing the notes from Sept 20th. I'll accept that I've misunderstood the semantics... Apologies to Domenic for any confusion on this point.</div>

<div><br></div><div><br></div><div>Rick</div><div><br></div><div><br></div><div><br></div><div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">

<div class="gmail_quote"><div class="im">
<div>†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">


<div><div><div><br></div><div>I was under the impression the temporal dead zone was about use-before-definition, not use-before-assignment.</div></div></div></blockquote></div></blockquote><div><br></div></div><div>Yes.</div>

<div class="im"><div>
†</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">


<div><div><div> </div></div></div></blockquote></div><div>There is no deadzone in the former, it's use-before-assignment†</div></blockquote><div><br></div></div><div>That is not my understanding.†<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div class="h5">
<div><div>†</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div><div><div>(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:</div>


<div><br></div><div>"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."</div>


<div><br></div><div>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.</div>


</div></div></blockquote><div><br></div></div><div>I'm not sure the full temporal deadzone semantics are even in a draft yet (like lots of things)†</div><div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">


<div><div><div><br></div><div><br></div><blockquote type="cite"><div>Not sure of the number, but there is a slide titled "Block Scoping" with this:</div></blockquote><div><br></div><blockquote type="cite"><div>

<div>
if (Math.random() > 0.5) {</div><div>† function go() {</div><div>† † console.log("gone!");</div><div>† }</div><div>† ...</div><div>}</div><div>assert(typeof go === "undefined");</div></div></blockquote>


<div><br></div><blockquote type="cite"><div>I'm not sure I get what this one is trying to illustrate, because "go" will always be initialized, regardless of the condition</div></blockquote><div><br></div><div>


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.)</div>


</div></div></blockquote><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div><div><div>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."</div>


<div><br></div><div>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.</div>


<div><br></div><blockquote type="cite"><div>new Set(...document.body.children);</div></blockquote><div><br></div><blockquote type="cite"><div>is a Syntax Error, use:†</div></blockquote><div><br></div><blockquote type="cite">


<div>new Set([ ...document.body.children ]);</div></blockquote><div><br></div><blockquote type="cite"><div><div>Same for:†</div><div>new Set(...array)</div><div>Math.max(...array);</div><div>Math.max(0, ...array, 5, ...array2);</div>


<div>new Date(...dateFields);</div><div>array.push(...array2);</div></div></blockquote><div><br></div><div>I don't think any of these is a syntax error, since spread works for function calls/constructs too. See <a href="http://tc39wiki.calculist.org/es6/spread/" target="_blank">http://tc39wiki.calculist.org/es6/spread/</a> 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!</div>


</div></div></blockquote></div><div>Not according to SpiderMonkey, so someone has a bug.</div><div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div>
<div><br></div><div>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...</div><div><br></div>


<blockquote type="cite"><div>Weak Sets aren't specified yet. Might be wise to omit that?</div></blockquote><div><br></div><div>Yeah, probably a good place to trim the fat. They are harmonious though, right? Since they're necessary for revocable proxies.</div>


</div></blockquote></div><div>They are, but no like I said, no spec yet</div><div><div>†</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div><div>
<br></div><blockquote type="cite"><div>One of WeakMap's best use cases is private data...</div></blockquote><div><br></div><blockquote type="cite"><div>... 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 :)</div>


</blockquote><div><br></div><div>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.</div>


</div></blockquote><div><br></div></div><div>It's not silly when you don't have symbols available.</div><div><br></div><div>Another better example is using a DOM node as a key to associate data</div><div>
<div><div>†</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div><div><br></div><div>Again, thanks for your help, and see you tomorrow!</div></div>

         
         
         
         
    </blockquote>
     
    <div>
        <br>
    </div>
</div></div><br></div></div><div class="im">_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>† † Cheers,<br>† † --MarkM<br>
</font></span></div>
</blockquote></div><br>