==.md

@aredridel

Thought of the moment: I never use === in javascript. I find that every time I need it, I've made a boneheaded design flaw elsewhere.

‏@chris__martin

@aredridel === is a promise to the maintainer who comes after you that you knew what you were doing.

‏@aredridel

@chris__martin Heh. For me it's a signal that they didn't know what they were operating on.

I guess this is actually the same debate as i > 0 vs. i != 0 to check whether i is positive in a situation where you know i is supposed to be a nonnegative integer. The i > 0 school of thought says it's a good cover-your-ass strategy because it works even when i is negative, whereas the i != 0 crowd says that writing i > 0 is bad because it just demonstrates a lack of confidence in the constraint.

Hm. I think in that case, I'd prefer the i > 0 case, which seems contrary to my preference for ==, but let me explain.

=== really hints to me that there's three cases. "Exactly what I meant" and a yet-to-be-differentiated "something else of that type" and "uh what?" -- especially when it's used following a typeof check (which I see a lot in that style of code)

I'd rather the loose type ==, "value I was looking for, or close enough to not care" and "not", or "greater than zero" or "not". They're both conditions that imply a certain closure over the input space.

I also tend to look for meaning in code -- the i != 0 case really says 'not zero' not 'positive number'. If I wanted to clarify "number", I'd write Number(i) > 0, not typeof i == 'number' && i > 0. It's got a lower npath complexity and a clearer meaning.

Hm. I think in that case, I'd prefer the i > 0 case, which seems contrary to my preference for ==, but let me explain.

Heh, I actually intended for i > 0 to be analogous to ==. I suppose it sort of goes both ways...

the i != 0 case really says 'not zero' not 'positive number'

In the case where the anticipated type is "nonnegative integer", the meanings of those descriptions are identical, and in many cases neither is a more intuitive or valid phrase than the other.

It seems like you and I are looking at the code from different angles. You're describing a perspective of "I've received some arguments, now how can I do what the caller probably wanted", and I'm saying "I'm going to define a clear API over particular types, and a caller that doesn't use them is erroneous".

I find it easier to think within restricted types, in a smaller space. Ultimately, in that sense, I suppose the question to me is moot. Because really all we're discussing is what the program's behavior should be when the behavior is undefined, and I don't think one ought to give that any thought.