Default operator strawman - ||| rather than ??

Domenic Denicola domenic at domenicdenicola.com
Thu Jun 14 09:58:41 PDT 2012


In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist.

Very roughly, it becomes undefined = caller error outside of my control, null = my error and I should use the API more correctly.

On Jun 14, 2012, at 11:27, "John Lenz" <concavelenz at gmail.com<mailto:concavelenz at gmail.com>> wrote:

My two sense.  In my experience (large applications, rather than tight libraries), distinguishing between null and undefined is the exception, not the rule.  When it is distinguished, as often as not the author would be more correct in either including null or making an property existence check (foo in bar) rather than an explicit check for undefined.

On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich <brendan at mozilla.org<mailto:brendan at mozilla.org>> wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete.  Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.

This is intentional, believe it or don't :-P.

In ancient days, void 0 was the only way to spell undefined, and users immediately tested o.p != null to existing-check. There was even some confusion where missing array elements in primordial JS evaluated to null not undefined. Argh, I had made myself forget that, now I remember.


However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.

Agree still. I do not see use-cases for including null. Maybe they exist, though -- someone please cite some github-hosted JS.

Even the Node workaround/premature-optimization of storing null rather than using delete doesn't argue for defaulting based on LHS value in {null, undefined}.


 Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.

It is screwed up but for reasons. Bad reasons, kind of like history or biology. Not just Homer Simpson "Life is just a bunch of things that happen" randomness, mind you! :-P

The most principled reason I've heard, IIRC from @jashkenas, is that null and undefined are confusingly similar, in part due to being ==. This is true, but I still do not see actual use-cases where null is passed into code that uses || to select a default value. Would love to see such real-world code.

/be

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120614/2a25cf9f/attachment.html>


More information about the es-discuss mailing list