Home

Blog

Contact

Resume for Steven E. Newton

Papers

Readings for Code Janitors

Services


Steven E. Newton
Crater Moon Development
© 2003-2022

Functions on the Heap

21 Oct 2022 467 words. (3 min)

Modelling the real world

The history of object-oriented programming started with a simple idea, very technical and low-level. Instead of having the blocks in a block-structured language having a stack frame, move the block – data and code – onto the heap. As a result, instead of the block being popped off the stack at the end of execution and discarded, the block still existed, and could be accessed again, if the program held a reference to it. In short, functions on the heap.

What does “on the heap” mean for a function? Typically blocks are lexically scoped, and considered functions when they are named and can be called from other parts of the program. Well, ordinarily, in a block-structured language, when you enter a function a stack frame is created, and the parameters are either copied to or referenced from within the frame. Variables local to the block are uninitialized, and so must be assigned a value. When the block, the function, exits, the stack frame is deleted and all the local variables become undefined once again, and the parameters revert back to the values they had before the block was entered. (By-reference parameters can appear to change if the value of the referee was changed, but we won’t complicate things further).

The next time the block is entered (the function is called) all the stack frame creation and initialization must be repeated. What Nygaard did was to move the function onto the heap, where is continues to exist after it is created and called. In the next call to the function, the local variables are still at whatever value they were when the last execution of the block finished. What results is variables retaining their values as long as the program executes, but are visible only within the lexical scope where they are defined. That ends up being powerful and useful way to structure and organize programs. Once the block is capable of existing beyond a single invocation, naming the blocks, and referring to them from multiple places, becomes useful.

In the original Design Patterns book by the “Gang of Four”, (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides), one of the principles is “encapsulate the thing that varies”. By using the technique of functions on the heap, this “thing that varies” becomes not only the “variables” within a block, but the operations which are associated with the block as well.

Perhaps the most simplifying insight gained from looking at objects this way is how it says nothing about types, certainly not in the strictly defined way seen in languages like Java. Abstract data types and hierarchies of abstractions get all the attention in some programming practices. It’s well worth the time to explore the implications of objects as long-lasting named functions on the heap.

<-Code Janitor Unit Testing Randomness ->