Andreas Rossberg wrote:
On 16 August 2012 23:47, Brendan Eich<[email protected]> wrote:
Andreas Rossberg wrote:
On 16 August 2012 00:35, Rick Waldron<[email protected]> wrote:
It would be far worse to have a different type of value as a return,
right?
Actually, no. It is far better to have something that produces failure
as immediately and as reliably as possible when used improperly.
Sentinel values are a prominent anti-pattern.
Spoken like a true ML'er :-P.
Well, in the pre-ML world I've been brought up in, it was still
considered good software engineering practice, independent of
language, static or dynamic (and ML has its share of violations, too
;) ).
When "failure" means failure, I agree.
-1 as an out-of-band (for non-negative indexes) return code is actually
easier to test
Why is it easier to compare against constants -1, NaN, or "" than to,
say, null or undefined? And if so, wouldn't that be something that
might be worth correcting? Question mark operator, anyone?
let index = s.find(...)
if (?index) { // equivalent to index !== undefined
...
} else {
// err...
}
We've toyed with that operator, but my point was that you don't need an
if of that kind of you can write a combined index test, e.g. in a cheezy
split-like example:
js> var s = "a b c "
js> var a = []
js> var i, j = -1
js> while ((i = s.indexOf(' ', j+1)) >= 0) { a.push(s.slice(j+1, i)); j
= i; }
5
js> a
["a", "b", "c"]
In this case, undefined as indexOf sentinel value would work too because
it converts to NaN -- but null would not work (it converts to 0). Using
an "in-band OOB " (for number type) sentinel wins.
Ultimately, it boils down to careful API design. For some operations
there is a useful neutral value to return in edge cases. For others,
there isn't.
I hope it's clear from my examples and particular arguments that I agree!
Then the conciseness and clarity of the test matters, and typeof
rv != "number"is the wrong tool compared to rv< 0.
I agree that typeof is the wrong tool, but rv !== undefined seems
reasonable to me.
See above. Relying on undefined -> NaN could work for numeric contexts,
but (the charAt example) preferring undefined to "" is likelier to make
"DuckPigundefinedCow" than "DuckPigCow", ceteris paribus :-P.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
