Default operator strawman - ||| rather than ??

Tab Atkins Jr. jackalmage at gmail.com
Wed Jun 13 07:55:55 PDT 2012


On Tue, Jun 12, 2012 at 6:33 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
> On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
>>> On the other hand, non-existent properties are a use-case.
>>> CoffeeScript provides a similar feature, but for null properties.
>>>
>>> For example, the following:
>>>
>>>    o =
>>>     a: 1
>>>     b: 2
>>>
>>>    alert o.c?.d
>>>
>>> compiles to:
>>>
>>>    var o, _ref;
>>>
>>>    o = {
>>>      a: 1,
>>>      b: 2
>>>    };
>>>
>>>    alert((_ref = o.c) != null ? _ref.d : void 0);
>>>
>>> Special-casing undefined makes as much sense as special-casing null,
>>> like CoffeeScript does.
>>>
>>> My point is that it is not obvious whether the non-existent properties
>>> use-case should be "undefined"-specific or "null"-specific (or both).
>>
>> That's... pretty wrong.  In the example above, o.c returns undefined,
>> not null.  If CoffeeScript *actually* compiles to the code you posted,
>> then it only works because they're using != instead of !==, and null
>> and undefined are both falsey.  However, it'll break if o.c is defined
>> and is a falsey value like 0 or false.
>>
>> Try it.  Put the following in your nearest console and see what it returns:
>>
>> ({a:1, b:2}).c === undefined
>
> CoffeeScript's property checking returns "undefined" if the property
> is either undefined or null, and returns the property itself
> otherwise.
> If the property is false or 0, it returns the property (either false or 0).
> I don't understand why you say it breaks if o.c is a falsey value like
> 0 or false.
>
> The following code:
>
>    Boolean.prototype.d = 'Property'
>
>    o =
>     a: 1
>     b: 2
>     c: false
>
>    alert o.c?.d
>
> will show "Property", as we'd expect.
>
> My point still stands. Being "undefined"-specific is arbitrary.
> CoffeeScript could have been "undefined"-specific; they were
> "undefined" + "null"-specific, which I believe makes more sense.

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.

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.  Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.

~TJ


More information about the es-discuss mailing list