Default operator strawman - ||| rather than ??
herby at mailbox.sk
Wed Jun 13 02:08:35 PDT 2012
Thaddee Tyl wrote:
> On Tue, Jun 12, 2012 at 10:17 PM, David Herman<dherman at mozilla.com> wrote:
>> On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
>>> 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.
>> Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria.
> "undefined" and "null" share a lot of behavior that other falsy values
> don't have.
> The most critical one is to throw a TypeError on some occasions,
> including when invoking the abstract ToObject operation.
> Besides, it often has a similar meaning: I have seen in a lot of code
> a de-facto standard wherein null is used to indicate a value that is
> voluntarily undefined. You can see this pattern all over node.js code,
> for instance.
Yes. I find this pattern a little smelly, though. It is an optimization
for V8 - delete foo.x changes foo to plain slow hashtable, but foo.x =
null does not.
> This lets the user know when a parameter was meant to be set to
> nothing, and when we should use a default parameter instead.
> Harmony's default parameters will make this easier, while letting a
> null value through -- which will make this pattern even more common.
But here, it is semantic difference - null means "nothing, chosen by
will". Undefined means "nothing, as a consequence of not being defined".
> On the other hand, we often want to react in a certain way if the
> parameter is not set, either because it was not supplied or because it
> was set to null.
I find the "or" here a bit misleading - to react if parameter is not set
is to react to undefined.
> Besides, the null value can be obtained from the standard library,
> when calling certain methods.
> Object.getPrototypeOf(...), string.match(...), even calling the toJSON
> method of a Date can return null.
Object.getPrototypeOf(...) return null for a reason. It is not
"semantically undefined", it is very well defined, being "the prototype
chain stops here, no more parents".
> Having a way to deal with those return values by providing a default
> value would be nice.
As I see it, it is much clearer (in the good code design and style
sense) to only react to undefined.
But under "paving the cowpaths" philosophy, I am afraid null+undefined
is what will be considered as the implementation.
P.S.: It also saves more code if ??/?= will react to undefined. Properly
testing undefined needs
typeof foo === "undefined"
while properly testing for undefined+null only needs
foo == null
P.P.S.: It would be helpful if delete could be made fast in V8 and
foo=null discouraged... though I can't imagine how.
More information about the es-discuss