• Contents

# 1. Introduction

This document explores some of the more unusual idiosyncracies of the JavaScript language, some of which may trip you up if you're not aware of them.

# 2. Curious Expressions

Following is a list of expressions that are all true (i.e. the result of the expressions is always the boolean value `true`). Some of the expressions are cute or ironic to look at. Others may just be plain puzzling to the uninitiated. Explanations appear below the expressions...

```(7 / 100) * 100 != 7
```

Because of the way that JavaScript represents floating point numbers internally, the expression `(7 / 100) * 100` actually produces the result `7.000000000000001`. It's not often that humans are better at computation than computers, but this would be one such occasion.

```100000000000000000000 + 1 == 100000000000000000000 - 1
```

Another artifact of JavaScript's rather weak internal representation of numbers. `100000000000000000000` is represented internally as a floating point number that can be expressed in scientific notation as `1e+20`. Given the precision of JavaScript's floating point number representation, `1e+20 + 1` is equivalent to `1e+20 - 1`.

```typeof null == 'object' && !(null instanceof Object)
```

This one is a bit hard to explain, especially in light of the fact that the statement `typeof new String () == 'object' && new String () instanceof Object` is true.

```typeof NaN == 'number'
```

Yeah, so in JavaScript `NaN` is a special value for the `number` type. So, the expression is technically correct, if appearing a little contradictory on the surface.

```typeof !NaN == 'boolean'
```

For the purposes of boolean logic, notting `NaN` produces the boolean value `true`. This is not to say that `NaN` is equivalent to the boolean value `false`, though. One could make the argument that it would be more correct for coercing `NaN` to a boolean type to produce the result `NaB` (Not a Boolean), but JavaScript has no such concept of a boolean value that is in the paradoxical state of being neither `true` nor `false`, or both, or an indeterminate one.

```NaN * 2 != 2 * NaN
```

Yeah, so this one just seems plain wrong on the surface. Why would swapping the two operands make a difference? Swapping operands in a multiplication, we have been taught, does not affect the outcome. So, then, shouldn't the two sides be equal? The trick comes in the odd behavior in JavaScript that the value `NaN` is not equal to itself. So, it turns out that both sides in the boolean expression do produce the same result: they both produce the result `NaN`. But, because `NaN != NaN`, so the two sides - while having the same value - are not equal.

```(NaN != NaN) && !(NaN < NaN) && !(NaN > NaN)
```

Ok, so if `NaN` is not equal to itself, then it must be either greater than itself, or less than itself, right? Ummmm, yeah. Well, not really. Even though `NaN` is not equal to iself, it is also not less than or, conversely, (and by implication) greater than itself. This falls squarely into the category of `strange but true`. Robert Ripley would be proud.

```(NaN && !NaN) != (!NaN && NaN)
```

So, both `NaN && !NaN` and `!NaN && NaN` produce the result `NaN`. Now, because `NaN` is not equal to itself, the two seemingly equivalent boolean expressions turn out not to be equivalent - even though they produce the same result. This is kind of a "paraphrasing" of the `NaN * 2 != 2 * NaN` case.

```(1 != NaN) && (1 == !NaN)
```

Just because `1` is not equal to `NaN`, it doesn't follow that `1` should equal `!NaN`. It's just a luck that the subtle underlying logic resembles a simplistic logic in this case. `1` is not equal to `NaN` because nothing is equal to `NaN`, but the reason `1` is equal to `!NaN` is because notting `NaN` produces the boolean value `true`, and `1` is equivalent to `true` in a non-strict equality operation.

```isNaN (true) == false
```

Yeah, so you may have been lulled into thinking that a boolean is not a number. Seems perfectly reasonable, eh? Well, not so fast! The `isNaN` function coerces its single argument to a number type by invoking the argument value's `valueOf` instrinsic method. Now, for boolean type values, the built-in `valueOf` converts the boolean value `false` to `0` and the value `true` to `1`. At this point, the `isNaN` function is dealing with a value that has been resolved to a number, so it returns `false`. Not exactly what you might expect (kind of like life).

```isNaN (new Boolean) != (typeof new Boolean != 'number')
```

This is kind of a restatement of the previous example. While `isNaN (new Boolean)` produces the result `false`, `typeof new Boolean != 'number'` produces the result `true`.

```isNaN (NaN) == !isNaN (!NaN)
```

So, `NaN` is definitely not a number, so `isNaN (NaN)` produces the result `true`. Now, as shown earlier, `!NaN` produces the result `true`. So, `isNaN (!NaN)` produces the result `false` because - as also shown earlier - the `isNaN` function coerces a boolean argument to a number and, therefore, returns `false`. Now, notting that produces `true`. So, the two sides of the equality operation are `true` and equal. But it's not because the "inner" and "outer" nots in the right hand expression "cancel" each other out, or anything quite that simplistic.

```isNaN (true) == isNaN (false)
```

The `isNaN` function always returns `false` when receiving a boolean argument, so the both sides of the equality operation are `false` and, therefore, equal.

```isNaN (5) == isNaN (isNaN (5))
```

On the left side of the equality, the number `5` is being tested for not a number, which unsurprisingly produces the result `false`. On the right side, there is an extra layer of `isNaN`. The inner test produces the value `false`, like the left side. The outer test also produces the value `false`, because the `isNaN` function returns `false` if it is supplied with a boolean argument. So, adding the extra layer of `isNaN` keeps the value `false` and both sides of the equality are equivalent.

```isNaN (new Number) == isNaN (isNaN (isNaN (isNaN (isNaN (isNaN (isNaN (new Number)))))))
```

You can extrapolate from the previous example, of course. It really doesn't matter how many layers of `isNaN` you add to the right side. Value's still gonna stay `false`.

```isNaN (NaN) != isNaN (isNaN (NaN))
```

Unlike the previous two examples, the same cannot be said for testing `NaN` for not a number. In this case, the left side produces `true`, but on the right side the inner test produces `true` while the outer test then produces `false`.

```isNaN ('5') == false
```

Hmmmmmmmmmm....... just like you might have thought that a boolean was not a number, you might also have thought that a string is not a number. Once again, because the `isNaN` function invokes the `valueOf` instrinsic method on its argument to coerce a number, the string `'5'` is successfully coerced to the number `5`, and so `isNaN ('5')` returns `false`.

```isNaN ('five') == true
```

Not all strings are created equal. You may have been taught that five is a number, but JavaScript doesn't think so. Apparently, nobody taught JavaScript to read English. Coercing the string value `'five'` to a number produces the value `NaN`, which - while not equal to itself - at least tests true for not being a number.

```isNaN (!'a number') == false
```

Ok, so this one is just trying to be too cute for its own good. It says quite emphatically `!'a number'`, so shouldn't JavaScript pay attention and oblige by testing true for not a number? Well, that's about as ridiculous as expecting that the expression `isNaN ('I am a number, damn you')` should produce the result `false`. As it turns out, notting any non-empty string produces the boolean value `false`, because a non-empty string is considered equivalent to `true`. Now, as shown earlier, the `isNaN` function tests false for any boolean argument, because the boolean argument is successfully coerced to `0` or `1`.

```isNaN (!!'a number') == false
```

Yeah, so don't think that adding another not before the `!'a number'` will change the outcome. You're still supplying a boolean argument to the `isNaN` function. You could also express this as `isNaN (!'a number') == isNaN (!!'a number')`.

```(null + null == 0) && (0 + 0 == 0) && (null + null != null)
```

So, if `null + null` is equal to `0`, then `null` seems like it's being treated as `0`. So, why isn't `null + null` equal to `null`? After all, we know that `0 + 0` is equal to `0`. What's going on? Simple. The value `null` is coerced to the number value `0` when used in a numerical operation (such as summing), but it is not coerced when involved in an equality test. The value `0` is not considered equivalent to `null`.

```(0 != null) && (!0 == !null)
```

As shown earlier, the value `0` is not considered equivalent to the value `null` in equality tests. However, notting both `0` and `null` produces the result `true`. So, while `0` is not equivalent to `null`, `!0` is equivalent to `!null`.

```(+null == +false) && (null != false)
```

Similar to the previous example, both `null` and `false` resolve to `0` when coerced to a number, but are not considered equivalent when compared to each other in an equality type operation.

```true == false + 1
```

Adding `1` to `false` makes it `true`? Well, actually, adding `1` to `false` first coerces `false` to the number `0` and then produces the result `1` upon adding `1`. Now, `1` is considered equivalent to `true` when involved in an equality operation.

```(typeof true == 'boolean') && (!typeof true == false)
```

Well, it's obvious that the type of the value `true` is `'boolean'`. Now, `'boolean'` is a string value, and notting any non-empty string produces the result `false`, so `!typeof true` gives you `false`.

```typeof new Boolean == 'object'
```

This just doesn't seem to make sense, unless you understand what's going on. You might be tempted to think that `typeof new Boolean` should give you `'boolean'`. As it turns out, the type of value that is created using JavaScript's `Boolean` core object is not the same as the type of a variable assigned with a simple boolean value. When using the `Boolean` core object to construct an object, you get just that: an object, and not a primitive boolean value.

```typeof !new Boolean == 'boolean'
```

To add irony to the mix, if you not an instance of the `Boolean` core object and then get the type of that result, you then get `'boolean'`. On the surface, it may be strange to look at. Basically, notting any object in JavaScript produces the result `false`, which is a boolean type value, so `typeof !new Boolean` is `'boolean'`.

```typeof typeof undefined == 'string'
```

So, the inner `typeof` operation produces a result that is a string, even if its value is `'undefined'`. Therefore, the outer `typeof` operation produces the result `'string'`.

```typeof window.defined == 'undefined'
```

So, this is not guaranteed to always be the case, but it's a good bet that the `window` object doesn't have a property defined called `defined`. So, it looks like a contradiction, but it's about as weak an apparent contradiction as saying `var number = 'string'`.

```typeof (window.undefined = 'defined') == 'string'
```

If you want to just get mad with trying to confuse the issue. Nuff said.

```(typeof function () {} == 'function') && (typeof function () {} () == 'undefined')
```

So, naturally the type of an empty anonymous function is `'function'`. But, if you add parentheses right after the empty function declaration, then you are essentially calling the function immediately after declaring it. Because the function is empty, it returns the result `undefined`, the type of which is the string `'undefined'`.

```(Infinity * 0 != 0) && (Infinity * 0 != Infinity) && (Infinity * 0 != NaN)
```

So, what exactly do you get when you multiply infinity by zero. You may initially think you should get zero. Not so. Do you get infinity? No. Do you get `NaN`? No? Then what?!?!? Infinity multiplied by zero is not equal to anything then? Kind of. So, actually, you do get `NaN`. And, as shown earlier, `NaN` is not equal to itself, so `Infinity * 0 != NaN` is true.

```!new Boolean (false) == false
```

Seems like when you not `false` you should get `true`. Problem is, in this case you're not notting the primitive value `false` but an instance of JavaScript's `Boolean` core object instantiated with the value `false`. Notting any object in JavaScript produces the boolean value `false`. This behavior would appear to make the `Boolean` core object less compelling, since an instance of this object is not interchangeable with a variable set to a primitive boolean value.

# 3. UIZE Trivia

 "uize" is the traditional Scottish spelling of the word "use". "UIZE" is the call sign of the Russian Federation ship BESSTRASHNYY, a rescue and salvage vessel built around 1963. Ironically, the bit.ly short URL http://bit.ly/UiZe links to an article about interceptors in Flex.