<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Sep 21, 2011, at 12:17 AM, Lasse Reichstein wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Destructuring allows, e.g.,<div>  var o = {};</div><div>  [o.x, o.y] = [1, 2];</div><div>I.e., a generic LValue as a Field.</div><div><br></div><div>Could this be generalized to working outside of array/object braces in declarations, e.g.:</div>

<div>  var o.x = 42;   // Declared non-configurable</div><div>  const o.x = 37;  // Declared non-Wrtiable and non-configurable</div></blockquote><div><br></div>o must denote an object already, right? Just checking -- some might want o if unbound to magically be bound to a fresh object, which would be deeply wrong.</div><div><br></div><div><br><blockquote type="cite"><div>and the *real* reason for suggesting it, a highly convenient shorthand:</div><div>  function Foo.prototype.bar() { ... }</div></blockquote><div><br></div>This is an oldie, we talked about it in ES1 days, IIRC JScript supported (supports?) it.</div><div><br></div><div><br><blockquote type="cite">
<div>I think I have seen this suggested before, but it might just be Crockford's web pages at some point (perhaps the one suggesting "::" as abbreviation for ".prototype."). Has it been suggested for ES?</div></blockquote><div><br></div>"::" is wanted for guards. <a href="http://disnetdev.com/blog/2011/09/20/Contracts.coffee-Works-In-Node.js/">http://disnetdev.com/blog/2011/09/20/Contracts.coffee-Works-In-Node.js/</a> extends CoffeeScript to use :: for guard-ish contracts while leaving Coffee's use of :: intact. Yes, significant whitespace.</div><div><br></div><div><br><blockquote type="cite">
<div>There doesn't seem to be any syntactic ambiguity (but it can foil look-ahead on functions if function </div><div>calls are allowed as LValues, since "function foo()()()()()()()() { ... } " won't know which parenthesis</div>
<div>starts the arguments until it sees the end of them). </div></blockquote><div><br></div>I don't see how function foo()() is legal unless you are thinking of an extension such as ES4/JS1.8+ "expression closures" where the body can be an expression.</div><div><br></div><div><br><blockquote type="cite"><div>Ofcourse, "classes" might remove the usecase for "in place function declaration" above.</div></blockquote><br></div><div>Sure, but I've never understood why people want to write</div><div><br></div><div><div><font class="Apple-style-span" face="Courier">Foo.prototype.m1 = function (...){...};</font></div><div><div><font class="Apple-style-span" face="Courier">Foo.prototype.m2 = function (...){...};</font></div></div><div><div><font class="Apple-style-span" face="Courier">Foo.prototype.m3 = function (...){...};</font></div></div><div><font class="Apple-style-span" face="Courier">...</font></div><div><br></div><div>instead of</div><div><br></div><div><div><font class="Apple-style-span" face="Courier">Foo.prototype = {</font></div><div><font class="Apple-style-span" face="Courier">  m1: function (...){...},</font></div><div><font class="Apple-style-span" face="Courier">  m2: function (...){...},</font></div><div><font class="Apple-style-span" face="Courier">  m3: function (...){...},</font></div><div><font class="Apple-style-span" face="Courier">  ...</font></div><div><font class="Apple-style-span" face="Courier">};</font></div><div><br></div><div>The exact grammar for the dotted expression is unclear. Would you allow any member expression, even one with bracketed index expressions? Side effects? Where to draw the line?</div><div><br></div><div>In light of all this, I don't see a strong argument for allowing declarations to have dotted expressions instead of identifiers.</div></div><div><br></div><div>/be</div></div><br></body></html>