JavaScript OMG! #11 to #15

The Blurb: This is mostly just a bit of fun and in form of some rough notes as I’ve been sticking my head into a few JavaScript books and thought I’d write down what strikes me as odd/interesting along the way. Of course, I’ve written some bits of JavaScript but I’ve never really sat down and read up on it. I’m not trying to be definitive and nor am I trying to take a particular view – just poking around Smile

OMG #11 – Variable Scope and Hoisting

It was a bit of a surprise to find that JavaScript didn’t support the notion of local scope blocks as in;

function foo()
  var x = 10;
    var y = 10;
  // surprised to find that y still exists here.


but it’s pretty clearly stated but it was more of a shock to realise that this ultimately means that you can use variables before you appear to have declared them Confused smile

var globalVar = "Four";

function foo()
  // we set the local variable we didn't declare yet :-S
  globalVar = "One"; 

  // "One"

  // we declare the local variable seemingly after it's
  // already been used :-S The function will only be 
  // called now though.
  var func= function() 
  var globalVar = func();

  // "Three"


// "Four"

That, definitely, will take a little bit of getting used to Confused smile

Reference: Flanagan, “JavaScript The Definitive Guide”, Page 54.

OMG #12 – Bitwise Operators

This one really threw me. I can see how it comes about based on having only one kind of Number data-type in the language but I do think it’s pretty confusing in that the bitwise operators in the language behave as though they are working on 32-bit integers rather than as though they were working on 64-bit floating point values but I guess it’s a choice that had to be made.

I think, short-term, I’ll avoid working with bitwise operators in JavaScript Smile

Reference: Flanagan, “JavaScript The Definitive Guide”, Page 69.

OMG #13 – Equality and Strict Equality

I’ll nominate myself again for being ignorant of the fact that there’s 2 ways to check equality in JavaScript. There’s the regular “==” and then there’s the “===” and I hadn’t appreciated that they existed (along with “!=” and “!==”).

Of the two, I think I prefer === or the “strict equality operator” because, for me, it starts from the strong place of “if two values are of different types then they are not equal” Smile I play around with this and come up with no surprises;

var n = 1;
var s = "1";
var s2= "1";
var o = { x : 1 };
var o2 = { x: 1 };
o.valueOf = o2.valueOf = function() { return(this.x); }
var a = [1];
var a2 = [1];
var b = true;

// different type so not equal. nice. clear. good.
console.log(n === s);
console.log(n === o);
console.log(n === a);
console.log(n === b);
console.log(s === o);
console.log(s === a);
console.log(s === b);
console.log(o === b);
console.log(o === a);
console.log(a === b);

// different object so not equal.
console.log(o === o2);

// nothing is equal to null
console.log(o === null);

// except null
var nu = null;
console.log(nu === null);

// nothing is equal to undefined
console.log(o === undefined);

// except undefined
var un;
console.log(un === undefined);

// nothing is equal to NaN, not even NaN 🙂
var na = NaN;
console.log(na === NaN);

// o is equal to itself
console.log(o === o);

// but not o2
console.log(o === o2);

// s is equal to s2
console.log(s === s2);

// a is not equal to a2
console.log(a === a2);

when I move to the “not so strict” equality operator it all gets a bit more “gray” because there’s a whole tonne of conversions that the operator is prepared to try out on my behalf;

var n = 1;
var s = "1";
var b = true;
var o = { x: 1 };
o.valueOf = function() { return(this.x); }
var p = { x: 1 };
p.toString = function() { return(this.x + 1); }
// true. convert s to a number.
console.log(n == s);

// true. convert bool to 1.
console.log(b == n);

// true. use valueOf on o to turn it into a number.
console.log(o == n);

// true. convert b to 1, convert o to 1.
console.log(o == b);
// true. use toString on p to turn it into a number.
console.log(p == "2");

but I think it’s all pretty understandable although I guess the most “impressive” for me is that one of;

var b = true;
var o = {x : 1};
o.toString = function() { return("01"); }

console.log(b == o);

where if I interpret behvaviour correctly, the boolean is converted to a number and then the object is converted to a number and then they are equal Confused smile

Reference: Flanagan, “JavaScript The Definitive Guide”, Page 71.

OMG #14 – “use strict”

It feels like the “use strict” directive brought in for ECMAScript5 is definitely the way to go given the long list of changes that it brings to the language (e.g. “all variables must be declared”, “it is a syntax error for a function declaration to have two or more parameters with the same name”) and so on.

Here’s for more environments where “use strict” is supported.

Reference: Flanagan, “JavaScript The Definitive Guide”, Page 111.

OMG #15 – Magic of Short-Circuiting ANDs and Truthy/Falsy

I really like this one. I find in a language like C# it can be quite painful to index into a complex object model while all the time trying to protect yourself from the pains of a null reference exception. The magic of the AND operator returning the right value at the right time looks to make this a lot easier in JavaScript which I really rather like;

"use strict";

var policy =
      holder :
          firstName: "Fred",
          lastName: "Smith",
          age: 45

// like this 🙂
var age = policy && policy.holder && policy.holder.age;


Reference: Flanagan, “JavaScript The Definitive Guide”, Page 123.

To be continued – you can find the rest of these “JavaScript OMG!!” entries here.