<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Aug 4, 2011, at 3:15 PM, Oliver Hunt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Aug 4, 2011, at 2:29 PM, Brendan Eich wrote:<br><blockquote type="cite">1. return allowed from constructor?<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite">Consensus is: RESOLVED, return disallowed from class constructor body.<br></blockquote><br>What about return with no value -- there are cases where such early returns are useful, and you would not be allowed to specify your own value (eg. there's an implicit return of |this|).  Most class-oriented languages have this behaviour (C++, Java, C#, etc), those that don't support early returns, frequently don't support return-statements at all (eg. the various object-pascal dialects).<br></div></blockquote><div><br></div>That is a good point, one I think someone raised at the meeting (my note-taking failed there). This resolution was about banning return <i>expression</i>; in constructors, but not banning return; used well to avoid tortured and over-indented control flow.</div><div><br></div><div>The grammar at <a href="http://wiki.ecmascript.org/doku.php?id=harmony:classes">http://wiki.ecmascript.org/doku.php?id=harmony:classes</a> does not restrict <i>Statement</i> at all, currently. The return-the-result-of-an-expression restriction could be done grammatically but it is easier to do with semantics, prose in this case.</div><div><br></div><div><br><blockquote type="cite"><div><blockquote type="cite">3. private variable use-syntax<br></blockquote><br>My 2c:  i've always felt a prefix should be required to access a globally scoped variable/property in general, but no doubt people would complain about that degree of verbosity.  That said I'm unsure why there's such a desire to avoid standard scoping rules of every other language (where the properties of |this| are implicitly in scope),</div></blockquote><div><br></div><div>You must mean languages that have static typing.</div><div><br></div>We have covered this before:</div><div><br></div><div><a href="https://mail.mozilla.org/pipermail/es-discuss/2011-June/015125.html">https://mail.mozilla.org/pipermail/es-discuss/2011-June/015125.html</a></div><div><a href="https://mail.mozilla.org/pipermail/es-discuss/2011-June/015129.html">https://mail.mozilla.org/pipermail/es-discuss/2011-June/015129.html</a></div><div><a href="https://mail.mozilla.org/pipermail/es-discuss/2011-June/015196.html">https://mail.mozilla.org/pipermail/es-discuss/2011-June/015196.html</a></div><div><br></div><div><br><blockquote type="cite"><div> with a mechanism to disambiguate access to the global scope if necessary (As C++ does, although i'm not suggesting C++'s syntax).<br></div></blockquote></div><br><div>Object != scope, the Harmony scoping model is lexical. Mutable instances with mutable prototypes violate lexical scope if injected into scope environments.</div><div><br></div><div>Even if you managed to put just the private names that were declared by the class as private instance variable names (we agreed to take out the syntax for this, for the moment), how would you know whether other.foo where foo was private in the class should be the private name object, or the string-equated 'foo'?</div><div><br></div><div>Think of Point with private x, y and an equals method. Another method has to access a plain old object with public property x. You can't try private and then public (won't be right for edge cases with both names mapped, possibly differently along the prototype chain; won't be efficient). Unlike languages with static type information about |this| and other parameters, in JS you need to say when you mean to access a private-name-keyed property.</div><div><br></div><div>/be</div></body></html>