Erik Reppen wrote:
Well, I was thinking !== null for most tests I guess but I could see
potential for typeof in the simpler methods that return other stuff.
So by this standard would:
'squirrel'.match(/wombat/);
be better if it returned an empty array rather than null?
Probably not. Again, the main consideration is usability. If you want to
catch mismatch -- and regexp matchers do, often -- then with an empty
array on mismatch, you'd have to write
var m = r. match(s);
if (m.length == 0) { /* mismatch handling here */ }
or trickier equivalents, but not
if (!m) { /* mismatch handling here */ }
While empty array does convert to empty string, the match array in
general is not used as a concatenation part. Any captured groups would
add extra elements to the array, and a /g flag would make all the
matches pop out. The "blind concatenation" use-case isn't there, in my
experience.
Experience is what drivers good API design, namely user experience and
usability. Most match users want to know about mismatch and handle it.
Whether mismatch is "failure" or "fallback", it's a fork in the
program's control flow, most of the time.
This is much less so the case with charAt.
If that's the case, then I guess I wanted to clear the forest for the
sake of a few missing trees.
Systematizing a-priori based on a theory of failure or a one-true OOB
return value is probably a mistake. Sometimes -1 works, other times "",
yet others null or even a thrown exception. The design depends on the
particulars. Channel Aristotle, not Plato.
In what cases does a null-returning method make sense from a
language-design-perspective? Or is null also a side-effect of not
having try/catch from the start?
Null has its uses. If you think of undefined as "no value" and null as
"no object" and use undefined for any-value-returning methods, and null
for maybe-object returning methods, you won't go too wrong.
/be
On Thu, Aug 16, 2012 at 4:47 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Andreas Rossberg wrote:
On 16 August 2012 00:35, Rick Waldron<[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 15, 2012 at 6:02 PM, Erik
Reppen<[email protected]
<mailto:[email protected]>> wrote:
This topic has probably been beaten to death years
before I was even aware
of es-discuss but it continues to get mentioned
occasionally as a point of
pain so I thought I'd see if I couldn't attempt to
hatch a conversation and
maybe understand the design concerns better than I
likely do now.
Consistent Type Return for Pass and Fail?
The principle of consistent type-return has
occasionally skewered me as
somebody who came to non-amateur levels of
understanding code primarily
through JavaScript. I can see the value in maintaining
consistent types for
positive results but not so much for indicators that
you didn't get anything
useful. For instance:
* [0,1].indexOf('wombat'); //returns an index on
success or -1 to
indicate failure. -1 passed on to a lot of other array
methods of course,
indicates the last element. If you'd asked me the day
I made that mistake I
could have told you indexOf probably returns -1 on
failure to find something
but it didn't occur to me in the moment.
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. Also, you mention failure and it's
true that lack of try/catch in original-JS and ES1&2 meant APIs
had to overload return values with out-of-band failure codes.
However, JS hackers do not write refutable match expressions
cracking return value using typeof or better. *That* is the
anti-pattern here.
-1 as an out-of-band (for non-negative indexes) return code is
actually easier to test and works well with certain code patterns,
compared to a differently typed code. JS is not alone here, tons
of precedent even in other dynamic languages that do have
try/catch and even matching.
The issue is "failure". Sometimes not finding the wanted character
index is not failure but just a condition to test that leads to an
alternative strategem. Then the conciseness and clarity of the
test matters, and typeof rv != "number"is the wrong tool compared
to rv < 0.
However, I agree that there is no chance of fixing that for
existing libraries.
That's another thing. Deviating from existing patterns for new
APIs that have similar names and motivations is going to be a pain
for some users. It's not obvious to me that we have a real
"failure must be prompt" problem here that justifies breaking with
convention.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
