Discovering OOP

Before I'd ever really heard of OOP, I was simulating polymorphism by using dispatch tables in structs. I'd define a struct for a listbox, e.g. This would have members for the size of the list, the width, the position on the screen, etc. There would also be a linked list of the items to display. I'd pass these structs around to functions that operated on them. I believe this was called module-based programming. The data was encapsulated in that only certain functions in a certain source file (or module) were allowed to operate on it. So far, so basic.

But sometimes, I'd want to have different functionality on a single listbox (or on a group of similar listboxes). For example, when the user selected an item, maybe I'd want to display information about that item somewhere else. So I'd define a function that was called by the main listbox code when an item was selected. But this function didn't belong with in the main listbox module, since it might be particular to only one application or even only to one screen. So I added a function pointer to the struct. The main listbox code would call that function if the pointer was nonnull. Different listbox clients could define their own functions to get the behavior they needed, without cluttering up the main listbox module.

This is essentially polymorphism - using indirection to select a function to execute at runtime, based on the inherent "nature" of the struct, rather than its incidental contents. Of course, there could be many such function pointers in the listbox struct. Today, we'd recognize this as a dispatch table, implemented in C++ to support virtual functions. But this was 1985, and I'd never heard of C++ or polymorphism. I just knew that I wanted to paramaterize this data structure not only with data, but with behavior. And it worked really well. (This is all obvious to anyone's who's programmed in the last 20 years).

However, the solution wasn't perfect. I eventually came to want to be able to further refine the behavior. I wanted one listbox to act just like another listbox, but also do something additional when an item was selected. This is where inheritance comes in. I ended up adding another function pointer for these cases, that pointed to the original function, and that I could call from the new function. The new function could call the old function before, during or after the new code, or could even completely ignore the old function altogether.

However, this solution never seemed as clean as the first solution of using dispatch tables for polymorphism. It was too obviously hacky having to maintain these chains of function pointers, and too easy to screw up and create bugs.

So imagine my delight when, soon after, I got a job with Sierra On-Line, then (1989) the most prominent adventure game company. They had actually created their own language, SCI, that was a very pure implementation of OOP. I'll never forget that first night reading the documentation on my bed and just being consumed with this language that did things I wanted to do and even things I didn't know I wanted it to do.

Ever since then, I've run into lots of people who talked about the difficulties of making the paradigm shift to OOP. But not me. It was love at first sight.