'void' as a value

Brendan Eich brendan at mozilla.com
Mon Sep 9 10:09:48 PDT 2013

> David Bruant <mailto:bruant.d at gmail.com>
> September 9, 2013 2:51 AM
> Le 09/09/2013 11:41, Claude Pache a écrit :
>> * `undefined` means "no value", or "nothing";
>> * `null` means "empty value", or (well) "null".
>> Practical usefulness:
>> * ES5: JSON stringification of object: `null` means `null`, and 
>> `undefined` means "no value, don't include the corresponding key".
>> * ES6: default values in function arguments (and maybe destructuring 
>> assignment?): `null` means `null`, and `undefined` means "no value, 
>> take the default".
> This is all after-the-fact justification. I understand the usefulness 
> made of this feature now that we have the 2 values, but I wonder if 
> given the choice to start over a newJS would be designed with 2 such 
> values.

There's really no point, is there? FTR (I've written this before), I had 
both null and undefined because JS was under not only "make it look like 
Java" marching orders, it was meant to connect to Java, with objects 
reflecting both ways. This was LiveConnect, shipped in Netscape 3.

But from the start I had null for Java's object reference types, meaning 
"no object"; and undefined as the bottom of the semiattice, meaning "no 
value". Java didn't have a way to express primitive | reference unions, 
rather had boxing (has this changed?).

> Among the nonsense of undefined-as-a-value:
>     var wm = new WeakMap();
>     var o = {};
>     console.log(wm.has(o), wm.get(o)); // false, undefined
>     wm.set(o, undefined);
>     console.log(wm.has(o), wm.get(o)); // true, undefined

Why are you blaming undefined for this? If we didn't have it, the same 
design decision could have been made for null. Isn't this really a 
WeakMap design choice?


More information about the es-discuss mailing list