<div dir="ltr">What about setting arbitrary expressions as the value for prototype methods? Being able to use higher-order functions to dynamically create functions is very important for functional style programming. I use it very often to decorate functions, compose functions together, set partially applied functions as methods, etc. It seems to be impossible with syntax proposed here - I think adding it to the "safety syntax" is very much needed and should not be over looked.<br>

<br><div class="gmail_quote">On Sat, Mar 24, 2012 at 4:28 PM, David Herman <span dir="ltr"><<a href="mailto:dherman@mozilla.com">dherman@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div class="im"><div>On Mar 21, 2012, at 9:13 AM, Allen Wirfs-Brock wrote:</div><br></div><blockquote type="cite"><div style="word-wrap:break-word"><div><div class="im"><div>On Mar 20, 2012, at 11:32 PM, David Herman wrote:</div>

<br></div><div class="im"><blockquote type="cite"><div style="word-wrap:break-word"><div><div>Well, hang on now. The 'constructor' syntax is not "just the constructor property." It still carries special status; the semantics of a class says "look for the property called 'constructor' and make that the [[Call]] and [[Construct]] behavior of the class."</div>

</div></div></blockquote><div><br></div><div>Actually, the semantics is probably more like:  the value bound to the <classMame>  is the function object defined by the <methodDefinition> whose <propertyName> is "constructor".</div>

</div></div></div></blockquote><div><br></div><div>Yes, sure. Doesn't change the point: 'constructor' is still a special, distinguished method.</div><div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word">

<div><blockquote type="cite"><div style="word-wrap:break-word"><div><div>Regardless of whether we spell it 'constructor' or 'new' it requires special semantics that says "there's one distinguished method form in the body that determines the constructor of the class."</div>

</div></div></blockquote><div><br></div><div>There is one distinguished method that <i>is</i> the class object (aka, the constructor function).  A class declaration essentially desugars into the definition of a constructor function and a object that is the prototype associated with that constructor. </div>

</div></div></blockquote><div><br></div></div><div>Again, doesn't change the point: whether you spell it 'new' or 'constructor' it's still a distinguished method, and then you can desugar that however you want.</div>

<div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div>The question is how we spell that. This is 99.9% a surface syntax question. Tou could argue that spelling it 'new' should define a ["new"] method, or a ["new"] method and a ["constructor"] method, or just a ["constructor"] method. If the latter, it's semantically *identical* to spelling it 'constructor'. But even if we chose one of the other two alternatives, the semantic differences here are minor, and the ergonomics of the syntax matter.</div>

</div></div></blockquote><div><br></div><div>You need to drop the [ ]'s  (although I'm not sure what you meant by them...</div></div></div></blockquote><div><br></div></div><div>I meant that there is a property of the prototype that you can access via either p["new"] or p["constructor"] or both, depending on which semantics we decide to give. No matter what the surface syntax, any of those semantics is available to us. I say:</div>

<div><br></div><div>    a) spell it "new" -- ergonomics trumps corner cases; hard cases make bad law</div><div><br></div><div>    b) desugar it to the constructor function and the p.constructor property only</div>

<div><br></div><div>    c) i.e., don't create a p.new property -- no more prototype pollution please</div><div><br></div><div>    d) an explicit 'constructor' method overrides the implicit creation of the 'constructor' method but does not define the constructor function</div>

<div><br></div><div>Why d)? Remember, the .constructor idiom is a *very weak* idiom that many JS programs don't follow. If a JS program has some reason to use 'constructor' for a different purpose, trust them.</div>

<div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div><div>Personally I think the answer should be "A" which implies that we have class-side inheritance.   This is a departure from current practice but because "classes are functions" there is no way in ES<=5.1  to set up class side inheritance other than by mutating __proto__.</div>

</div></div></div></blockquote><div><br></div><div>I always found this the more appealing, but then again, if I'm supposed to be going with the opposite of my instincts (see above), then maybe I should disagree with you. ;)</div>

</div></div></blockquote><div><br></div><div>I would guess that your instinctive response comes from thinking about a "class" is something more than just  a composite of objects.  We can talk more about this later after I respond to Mark</div>

</div></div></blockquote><div><br></div></div><div>I think you misread me. My instinctive response agrees with yours, not Mark's.</div><div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word"><div>

<div>If the value of SOMEEXPRESSION is a constructor function (typeof == "function" && and has a "prototype" property) then the new constructor inherits from SOMEEXPRESSION and the new prototype inherits from SOMEEXPRESSION.prototype.  Otherwise, the new consructor inherits from Function.prototype and the new prototype inherits from SOMEEXPRESSION.  That is essentially the semantics I've defined for</div>

</div><div>       SOMEEXPRESSION <| function () {}<br></div></div></blockquote><div><br></div></div><div>I'm not happy with that semantics, for either classes or <| (I believe others have objected on the list to the special-case semantics for <| as well). Since functions are objects, you can pass functions into contexts that expect an object and those contexts don't need to care whether the object they have is a function or an object. So this will lead to WTFjs moments where people take an object they got passed in from someone else and create a class with it, and it won't be wired up right because they didn't realize the object was a function.</div>

<div><br></div><div>This kind of special-case ad hoc type testing in the semantics has a bad smell. It reminds me of stuff like the Array constructor that special-cases the number argument.</div><div class="im"><br><blockquote type="cite">

<div style="word-wrap:break-word"><div><div><div>B = do{</div><div>      let B = SOMEEXPRESSION <| function B(...) { ...};</div><div>      B.prototype= SOMEEXPRESSION.prototype <| {constructor: B, ...}</div><div>      B</div>

<div>}</div><div><br></div><div>(or to be maximally explicit}</div><div><br></div><div>B= do {</div><div>    let B = function B(...) {...};</div><div>    if (typeof SOMEEXPRESSION == "function" && typeof SOMEEXPRESSION.prototype == "object") B.__proto__=SOMEEXPRESSION;</div>

<div>    B.prototype= SOMEEXPRESSION.prototype <| {constructor: B, ...}</div><div>    B</div><div>}</div></div></div></div></blockquote><br></div></div><div>Nit: you'd need to bind the result of SOMEEXPRESSION to a temporary, to avoid duplicating side effects. </macrology nerd></div>

<div><br></div><div>Dave</div><div><br></div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><me><name>Nadav Ivgi</name><profession>Software Developer</profession><phone>+972-50-3650394</phone><blog><a href="http://www.shesek.info/" target="_blank">http://www.shesek.info/</a></blog><timezone>GMT +2</timezone></me></div>

</div><br>
</div>