Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Robert Martin <>
Date: Tue, 20 Jun 2006 12:55:56 -0400
Message-ID: <2006062012555670933-unclebob@objectmentorcom>

On 2006-06-13 06:24:00 -0400, "S Perryman" <> said:

>> EWD is indirectly one of the fathers of OO.  His name is on a book 
>> named "Structured Programming".  In that book Dahl and Hoare describe 
>> Simula 67, arguably the first OOPL.  They talked about how they 
>> stumbled upon the notion of objects by moving the stack frame of 
>> block-structured function from the stack to the heap.

> This is just bollocks.
> And not even corroborated by what Nygaard and Dahl have written
> themselves about the origins of Simula, or people who have researched
> the history of Simula (Jan Holmevik etc) . ***
> Simula had objects from day 1, long before the NCC ran into the
> trap that basing their language on Algol-60 sprung.

I didn't say anything about WHEN Simula had objects. I was talking bout the the way the idea was formulated. Below is thier own description of that formulation. Note the terms in which they couch our now familiar concepts of objects and constructors.

> If you wish to refute this claim, please quote the *exact text* from your
> sources that show how the NCC "stumbled upon" objects.

Structured Programming, Academic Press, 1972, p178-9. Including the following:

"In ALGOL 60, the rules of the language have been carefully designed to ensure that the lifetimes of block instances are nested, in the sense that those instances are the latest activated and are the first go go out of existence. It is this feature that permits an ALGOL 60 implementation to take advantage of a stack as the method of dynamic storage allocation and relinquishment. But it has the disadvantage that a program which creates a new block instance can never interact with it as an object which exists and has attributes, since it has disappeared by the time the calling program regains control. Thus the calling program can observe only the results of the actions of the procedures it calls. Consequently, the operational aspects of a block are overemphasised; and algorithms (for example, matrix multiplication) are the only concepts that can be modelled.

"In SIMULA 67, a block instance is permitted to outlive it's calling statement, and to remain in existence for as long as the program needs to refer to it. it may even outlive the block instance that called it into existence. As a consequence, it is no longer possible to administer storage allocation as a simple stack; a general garbage collector, including a scan-mark operation, is required to detect and reclaim those areas of store (local workspace of block instances) which can no longer be referenced by the running program."

Clearly these guys figured out that if you moved the block (e.g. the function stack frame) from the stack, to the heap, you get:

"...a wider range of concepts to be conveniently expressed..."

For those of you who aren't familiar with block structured languages, the reason that moving the block instance from the stack to the heap was so powerful was because in a block structured langauge every function can define sub functions within it. Thus (in a c-ish like syntax)

void f() {
  int i;
  void g() {
    i++; // refers to f::i
  return i;

This function will return 1.

So notice that a block has variables AND functions within it; and the functions within the block have access to the variables in the block. Just like an object. All this existed in Algol-60, but remained only marginally useful because the block instance was destroyed when f() returned.

The insight of the NCC (Norwegian Computing Center), and specifically Dahl and Nygaard, was that if you allocated the block instance on the heap (what they called the "local workspace of block instances") then the block could outlive the function that created it. That function is what we would now call a constructor, and the block-instance became (in their words) an object.

Robert C. Martin (Uncle Bob)  | email:
Object Mentor Inc.            | blog:
The Agile Transition Experts  | web:
800-338-6716                  |
Received on Tue Jun 20 2006 - 11:55:56 CDT

Original text of this message