Thaddee Tyl wrote:
On Tue, Jun 12, 2012 at 10:17 PM, David Herman<[email protected]> 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.
Herby
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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
