es-discuss Digest, Vol 79, Issue 38

Christina Whyte kurisu.whyte at gmail.com
Mon Sep 9 06:52:20 PDT 2013


>>> 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.

>Even if the two particular cases I've mentioned were not forecasted when
designing JavaScript, it does not diminish the value of the feature. When
designing JS, some decisions had been taken, whose usefulness or badness
has been understood only after experience.

That we've found uses for these types don't mean that they're the best we
could have done. In fact, we could have achieved the same without having a
Null type (let alone two!)

As for JSON serialisation, `Null` could be a special type for JSON alone,
that would not be able to be mixed with other types. And if accessing
object properties that are not there threw an Error instead, we wouldn't
have to worry about these things.

In this case, `foo.bar` would always yield a useful value if `foo` is an
object, because `bar` is guaranteed to be present in `foo` and to be an
actual value (not undefined/null). It can't be mixed with other things, and
we have no problems with iterating over `foo`.

If we are not sure `bar` exists in `foo`, a function would be defined in
`foo's` prototype that would return a `Maybe<T>` type. So instead of
blindly doing `foo.bar` when you're not sure `bar` exists, you'd use
`foo.get('bar') // => Maybe<T>`  or `foo.getOrElse('bar', 'defaultValue')
// => T | defaultValue`.

The benefits of this is that we get early errors where it matters, and
people are less likely to forget to deal with possible errors in their
applications, because dealing with such is made explicit — this still plays
well with the delegation semantics, since errors are thrown after we've
searched all the prototype chain.

Destructuring assignments could also have an explicit "I know this might
not exist, but I want a value anyways" semantics. ES6 Modules have this
*because* people want early errors (and for static linking I suppose?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130909/31b17074/attachment.html>


More information about the es-discuss mailing list