<div dir="ltr">Maybe this is wrong, but I'm in the habit of thinking that if something has a value of null, something in JavaScript code (mine or a library I'm using) explicitly set it to null. If something has a value of undefined, it was never set. For that reason, I'd prefer using undefined in this case over null.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace, monospace"> __  __</font></div><div><font face="monospace, monospace">/  \/  \</font></div><div><font face="monospace, monospace">\      /ark</font></div><div><span style="font-family:monospace,monospace;font-size:12.8000001907349px">               Object Computing, Inc.</span><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">  \  /</font></div><div><font face="monospace, monospace">   \/olkmann</font></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 19, 2015 at 10:54 AM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.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"><br><div><div>On Jan 19, 2015, at 5:51 AM, Claude Pache wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Le 19 janv. 2015 à 11:58, Andreas Rossberg <<a href="mailto:rossberg@google.com" target="_blank">rossberg@google.com</a>> a écrit :</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 January 2015 at 19:14, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Jan 17, 2015, at 9:53 AM, Domenic Denicola wrote:<br>> On Jan 17, 2015, at 12:31, Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>> wrote:<br>
>><br>
>> If the enclosing function is invoked as a call expression the value of  `new.target` is null<br>
><br>
> Just curious, why null instead of undefined?<br>
<br>
</span>null is used to indicate no [[Prototype]], so it seem to me to be a better match for this situation.<br></blockquote><div><br></div><div>Wouldn't the fact that null is a quasi-legal prototype strongly speak for using undefined here? Otherwise, it seems you couldn't distinguish Call invocations from Construct invocations with a prototype that has actually been set to null (which I suppose is legal?).</div><div><br></div><div>(In terms of proper option/maybe types, this is yet another case of a None vs Some(None) distinction.)</div><div><br></div><div>/Andreas</div><div><br></div></div></div></div></div></blockquote><div><br></div><div>`new.target` is a reference to the constructor, not the prototype, so the problem does not arise in practice.</div><div><br></div><div>But anyhow, I do think that `undefined` is semantically better here:</div><div><br></div><div>* `new.target === null` means: `new.target` has been set to "no object".</div><div>* `new.target === undefined` means: `new.target` has not been set.</div></div></div></blockquote><div><br></div><div>At the JS level, I don't actually think about `new.target` as something that is "settable". I think about it as an oracle that tells me about how this function was invoked.  null means it was invoked "as a function".  non-null means it was invoked as a constructor and the value is the object that `new` was applied to. </div><div><br></div><blockquote type="cite"><div style="word-wrap:break-word"><div><div><br></div><div>When you execute a function body with the semantics of [[Construct]], the value of `new.target` is the original constructor on which `new` was applied. If it was possible to have the semantics of [[Construct]] with no original constructor, then `new.target` would be `null` (no-object).</div></div></div></blockquote><div><br></div>But it isn't.  Reflect.construct ensures that an non-null value is passed to [[Construct]] as its second argument <br><blockquote type="cite"><div style="word-wrap:break-word"><div><div><br></div><div>But when you execute a function body with the semantics of [[Call]], there is no notion of "original constructor", and `new.target` is left with no value, i.e. `undefined`.</div></div></div></blockquote><br></div><div>I originally intended `new.target` to use `undefined` is the sentinel value to indicated "called as a function".  But as I wrote the spec. it felt better to use `null` in that role.  I think it's because using `null` seems more special.  `undefined` is used in so many places to indicated so many different things that it is hard to apply any generalized meaning to it.  On the other hand, `null` is used in only a few places in the ES spec. so its use seems to draw attention to the specialness of those situations.</div><div><br></div><div>But, I'd have no problem with changing back to `undefined` if there is a consensus in favor of that.</div><div><br></div><div>It really makes very little difference as `null` and `undefined` are both falsey values, so the preferred way to write a "called as a function" these should probably be:</div><div><br></div><div>`if (! new.target) ...`</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Allen</div><br></font></span></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></div>