Virtual Method Table

Today I'm going to blog about something called a "virtual method table".  I randomly caught a talk where the speaker was saying that teaching someone to sling code is not sufficient. The student has to also understand the theory and fundamentals behind what they are learning.  A great analogy he used was that a "plumber should know what's going on underneath the sink."  He then randomly threw out some computer science terms and concepts; and let me tell you, it was refreshing.

So often we see those "learn to code" websites where they promise to teach you how to program in XX hours.  Reminds me of a great Abstruse Goose comic:

Love this comic

It's a little dated in that it references the old "Sam's Teach Yourself C++ in 21 Days" book but for those of you who don't remember this series:

Oh the lies

I remember this well because I actually had this book.  And I remember I felt like such a failure when I'd take me multiple hours to get through a single "1 hr" lesson.  Frustrated I remember throwing the book aside.

The book that really taught me how to program was:

A Beast of a Book

I forget exactly which edition, but I won't forget the name of the book.  This particular edition is a whopping 984 pages of text and weighs 3.4 pounds.  It was a beast back then, and it's a beast now.  But it's that large b/c the examples are so thorough and the explainations so in depth (at least my particular version was, I can only assume the core of the book is still the same for the fifth edition).

I really enjoyed this book, which is why I wanted to highlight it today.  Ok enough aside, onto the content.

What is a virtual method table?  For that matter, what is a virtual method?  It's really simple.  A virtual method is just a function that can be overriden by an inheriting class.  Basic rules apply, like you need to have the same signature, but it's not much more complicated conceptually than that.  Virtual methods are a core part of object oriented programming.  They can help allow things like polymorphism to happen, a key of OOP.  (There's more to polymorphism than just this, but that discussion is out of scope right now.)

So how are virtual methods implemented?  That's where we get into virtual method tables.  A typical function is bound at compile time.  In other words, when you compile your language, you compile in the location of where your function will live.  So when your program runs, it's a simple jump instruction to the spot in memory where your function resides.  Your program keeps track of where you came from, so when your function is done, you just hop right back where you came from.

Virtual methods on the other hand cannot compile in the memory location, because, you the programmer, could have created an inherited class that overrides that method.  So the compiler cannot figure out during compile time, which exact implementation to jump to.  As a result, the compiler (or runtime, depending on the language/implementation) will create a bit of indirection, called a 'virtual method table' (one table for each class) that acts as a lookup to the proper implementation that should be invoked.  Each instance of your class will have a pointer to this special virtual method table so that when the virtual method is called, the virtual method table can be checked to see which method implementation we actually want to invoke.  Because we don't know precisely the location until runtime (when we check the table), this is called "late" binding (as opposed to compile time, or "early" binding).

Virtual method tables are awesome because it allows us to be flexible in the behavior of our program.  Nothing in life is free though.  This table takes up memory and because of the added hop to the table, then to the actual method, the performance is also slower than an early bound method.  So in C++, you have to explicitly declare which ones of your methods will be virtual by using the keyword...virtual.  Shocking name, I know.  In Java, every method is virtual by default, unless you declare that method to be final or static.

That is the basic concept.  A relatively simple solution to a simple problem.  You'll often hear these concepts refered to by a bunch of various names, but it all refers to the same thing.  A virtual method table is also called a virtual function table, or a virtual call table, or vtable.  But tomato tomato (works better when you say that part aloud).

Hopefully this teaches you something, or at the very least refreshes your memory on a topic you probably don't have to deal with daily.  Take care and happy holidays :)

JavaScript Generators

Intro

One of the things people are really excited about that is coming in EcmaScript6 (Harmony) are generators.  There is a lot of writing out there today on generators but for the most part, I found the writing to be too quick to skip over the fundamental question of what they are.  Basically I was looking for a tl;dr.  Cuz ain't nobody got time for that.

Definition

I actually really like Mozilla's definition.  Short and sweet:
"Generators are functions which can be exited and later re-entered. Their context (variable bindings) will be saved across re-entrances."

Allow me to paraphrase:
tl;dr Generators are special functions that save their variable state between calls.

Example

Now that you got the basic idea, let's look at an example.

First notice that the function definition has an asterick *.

//will double the number passed in
function* doubler(i){
  var doubled = i;
  while(true){
    doubled *= 2;
    yield doubled;
  }
}

Next notice the yield keyword.  We'll come back to that.  Let's take a look at the usage.

var gen = doubler(1);

The interesting thing is that calling doubler doesn't actually invoke the function.  A special object called an iterator is returned.  So gen holds an iterator, so lets see how to use that:

var result = gen.next();

Calling the next method on the iterator actually runs the doubler function, but stops when it hits the keyword yield (told you we'd come back to it).  And whatever you pass to yield (in this case the variable doubled), the iterator returns that.  So line by line:

var doubled = i;
//remember from above that i is 1, var gen = doubler(1);

while(true) {
 //nothing says that the iterator has to terminate. 
 //it can go on forever like this one does

  doubled *= 2;
  //doubled was 1, now its 2, b/c well 1*2 is 2

  yield doubled;
  //the iterator will stop here for now and return 2
}

So there you go, result should be 2.  Conceptually, that's sufficient to say, but in practice, the iterator takes 'doubled' and wraps it inside of a result object.  The result object has two attributes:

1.  The 'value' attribute which holds the value of 'doubled'.
2.  An attribute called 'done' that tells us if the iterator is done, which of course it isn't b/c we have a forever loop there.

{value: 2, done: false}

So what happens if we call next() again?

result = gen.next();

If you said

{value: 4, done: false}

Then congrats!  This is just the surface of how we can use generators, but once you understand this, the rest is cake.

Further Reading

If you would like to dive deeper into generators, check out this guide.  It's pretty detailed and explains some of the many ways you can use generators.

I also recommend the Mozilla documentation:

Using It Today

Great, you love generators now and want to use them today.  Unfortunately, the spec isn't officially finalized yet and not all browsers support it today.  To see who supports it, check out this table here.

You could also use transpilers like Traceur to turn it into regular JavaScript.

Or you can do what I did, and that's to use node.  Let's say all your JavaScript code is in generators.js.  Then just install node and run:

node --harmony generators.js

RubyNation Recap

This weekend I attended RubyNation, a great Ruby conference right here in DC.  Well technically it was at Silver Spring, MD, but still; I had a fantastic time.  All of the speakers and attendees were wonderful.  As usual, the best part was the human aspect.  Connecting and talking with people from all around the world that share the same love and passion that I have is something truly special and this conference was particularly fantastic.

That isn't to say the talks/presentations weren't amazing also.  If I had to sum up some of the main takeaways, they would be:

1.  Always keep reaching.
Do things outside of your comfort zone.  Force yourself to grow by challenging what you know and what you think you can do.

2.  Give back to the community.
Open source survives because a bunch of awesome people dedicate themselves to solving problems so you don't have to.  Do your part and give back in any way you can.

3.  TDD is not dead.
Writing good testable code is not a bad thing.  Knowing what to test and how to test can help you get insight into what you are building and can lead to a better design and better code.

That's it for now.  After the talks get posted online, I'll link them here.

JavaScript Hoisting

Today I'm going to spend a little bit of time on hoisting in JavaScript.  A very cool and useful feature if you know how it works, but painful and confusing if you don't.

So what is hoisting?  Hoisting is JavaScript's behavior of moving declarations to the top of your scope (typically either the top of the global scope or function if you are in one).

There are two main types of things that can get hoisted, variables and functions.  We will go through each one of these presenting example cases to help illustrate how they work.  And at the end we will put everything together with a short quiz that contain aspects of everything discussed here.

Variable Hoisting

Case 1: Using a variable that doesn't exist.

console.log(name);

If you run this script, you get

ReferenceError: name is not defined.

This makes sense.  The variable name wasn't defined anywhere and as such, our JS engine can't resolve it and blows up.

Case 2: Correctly defining a variable and using it.

var name = 'Jon';
console.log(name);

This declares and defines name, and then uses it.  This works as expected and you will see 'Jon' written out to the console.

Case 3: Defining name after usage.

console.log(name);
var name = 'Jon';

You would expect to see the same behavior as Case 1, a ReferenceError, but what you see instead is 'undefined' written out.  This is because of hoisting, in this case, variable hoisting.  The declaration of the name variable was hoisted to the top of this scope.  Notice I said declaration, not definition.  The definition stays right where it is.  This is why name is undefined when it gets printed out.  Let me rewrite what the JS engine actually executes after hoisting.

var name;  //gets the default value of undefined
console.log(name);
name = 'Jon';

As you can see, now the output makes sense.
What other things can get hoisted?  In the next section, I'll talk about function hoisting.

Function Hoisting

Just like variable declarations, function declarations can get hoisted too.  But fun bit here, since the declaration and definition are done together, everything gets hoisted.

Case 1:  Using a function that doesn't exist.

sayHi();

This gives us the same result as Case 1 above,

ReferenceError: sayHi is not defined.

This makes sense.  You can't use something that you haven't declared.

Case 2: Using a function correctly defined after we declare and define it.

function sayHi() {
  console.log('hi');
}
sayHi();

Output here is 'hi'.  We declare and define a function sayHi, and then invoke it.  Everything works and this code is easy to understand.

Case 3: Using a function before we declare and define it.

sayHi();
function sayHi() {
  console.log('hi');
}

The output here is the same as Case 2, we get 'hi' printed out.  This is because the entire sayHi function is hoisted to the top.  So when we invoke sayHi(), it already exists.  Let's take a look at the code after hoisting.

function sayHi() {
  console.log('hi');
}
sayHi();

Notice that it's exactly the same as Case 2.

Hoisting of a Variable Holding a Function

What about this case, if we have a variable that holds a function.  That function is typically anonymous (it doesn't have to be) and we often see it as such:

var sayHi = function() {
  console.log('hi');
}

How does this get hoisted?

Case 1: Using a function that doesn't exist.

sayHi();

This looks like Case 1 above and is.  It gives us the same result,

ReferenceError: sayHi is not defined.

Same reason as before, you can't call something that isn't declared.

Case 2: Using the function after we declare and define it.

var sayHi = function() {
  console.log('hi');
}
sayHi();

This works as expected and prints out 'hi' into the console.  We've properly defined an anonymous function, set it to a variable, and then later invoked it.

Case 3: Using the function before we declare and define it.

sayHi();
var sayHi = function() {
  console.log('hi');
}

Boom!  We get

TypeError: undefined is not a function. 

What happened here?  Why didn't hoisting save us?  It saved us for both variables and functions, why not this time?  It's very subtle, but if you apply the hoisting rules you have learned thus far, you can see why this failed.  Let's rewrite the code after hoisting is applied.

var sayHi;  //set to default value of undefined
sayHi();
sayHi = function() {
  console.log('hi');
}

Because sayHi is actually a variable here, the variable hoisting rule applies.  The JS engine declared the variable at the top of the scope, and left the definition where it was.  So at the time we try and invoke sayHi, it's actually set to undefined.  Obviously, undefined is not a function, which is what our exception complained about.

An important thing to remember here is that for variables, only the declaration gets hoisted, while as for a function, the whole thing gets hoisted.  So this has implications in that when a function gets hoisted, it's immediately accessable/invocable anywhere within that scope.  But if you have a variable containing a method, you can't actually invoke that method until the definition of that method.  Up until that point, the variable will hold the value 'undefined' which you have already seen.

Now let's put it all together.  Look at the code below and see if you can figure it out before I reveal the answer.

The Quiz

Taking everything you learned, what gets executed here?

var f = function() {
    console.log("Me original.");
}
function f() {
    console.log("Me duplicate.");
}
f();

Answer just below....

Answer

If you said 'Me original', you are right!  Wow, pat yourself on the back.  If you got it wrong, don't worry, I did too.  Let's see what this thing actually produces after hoisting, and then we'll tackle it step by step.

After Hoisting

var f;  //gets value of undefined
function f() {
    console.log("Me duplicate.");
}
f = function() {
    console.log("Me original.");
}
f();

First thing that happens is that the declaration of f gets hoisted.  Then, the function f gets hoisted.  Even though this looks weird, so far we are ok.  Odd as it looks, this is valid JS.  We just have a single variable, f, that contains a function that prints out 'Me duplicate.'.  Next we redefine f to print out 'Me original.'.  Finally we have our invocation.  This calls f which has been reassigned to an anonymous function that prints out 'Me original.'

Hopefully all this helps clear up the mystery of hoisting in JavaScript.


A lot of these examples were taken from some stackoverflow questions:
http://stackoverflow.com/questions/23889317/explain-this-javascript-name-clash
http://stackoverflow.com/questions/336859/var-functionname-function-vs-function-functionname