Ingalls' Tape

Smalltalk Introduction Dan Ingalls
- Worked at Xerox on Smalltalk project.

- Moved to Apple, where he was when tape was made.

- Now managing his family's business, a hotel in Appalachian moutains.

Listen for:

1. Object-oriented design process (hospital example).

2. Implementation ideas: run-time structures to support "dynamic lookup".

3. Use of "inheritance" and "polymorphism".

4. Why objects are less efficient.

5. Ingalls' test: What makes a language object-oriented?

6. Discussion of types.

Watch tape.

Topics from tape:

Terminology
Object : instance of some class

Class : defines the behavior of its instances

Selector : name of a message

Message : selector together with parameter values

Method : code found in a class for responding to a message.

OOP's and ADT's

Ingalls describes evolution from memory cells to ADT's and on to objects. How do ADT's compare to objects? Consider: 

	abstype matrix = ...
	with
		create(...) = ...
		update(m, i, j, x) = ...set m(i,j) = x...
		add(m1, m2) = ...
		...
	end;

1. add function takes two matrices as arguments.

2. call 
		add(x,y)
in this scope refers to *this* add function, so x and y must be matrices. If *add* were defined for complex numbers previously, then this declaration hides previous one.

How are objects different? Consider: 

	class matrix
		...		(representation)
		update(i,j,x) = ... set (i,j) of *this* matrix ...
		add(m) = ... add m to *this* matrix ...
	end

1. *add* function takes one matrix: the other matrix to add to this one.

2. call 
		x.add(y)   or (smalltalk) x add: y
Invoke the *add* method of x with parameter y.

Can defined other classes with *add* method: 
	x.add(y)	sum of ints  x,y
			       reals x,y			
			       matrices x, y
		        or add y to stack x
				    queue x
				      set x
"Dynamic Lookup" look for name *add* in lookup table of dynamic value of x. In Smalltalk, this lookup table is called a method dictionary. In C++, it is a virtual method table, or vtable for short.

Ingalls' polymorphism: x.add(y) can mean all these things.

Object-oriented structure vs. Conventional structure

Hospital Simulation:
Data: Doctors, Nurses, Orderlies

Operations: Display, Pay

With these operations and data, we get the following table of code: 

		Doctor		Nurse		Orderly
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  + Display  +  draw Dr.   +   draw RN     +  draw ord.      +
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  +   Pay    +  mega-bucks +   peanuts     +  peanut shells  +
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Conventional organization: by row 

	Display(x) =
	  case type(x) of 
		Doctor  : ["Display Doctor" ]
		Nurse   : ["Display Nurse" ]
		Orderly : ["Display Orderly" ]
	  end;
	end;

	Pay(x) =
	  case type(x) of 
		Doctor  : ["mega-bucks" ]
		Nurse   : ["peanuts" ]
		Orderly : ["peanut shells" ]
	  end;
	end;

Here code is grouped by operations.

- Easy to add a new operations, like PayBonus or Promote, but hard to add a new kind of data, like "Administrator" or "Intern".

OOP organization: by column 

	class Doctor =
	   Display = "Display Doctor";
	   Pay     = "mega-bucks";
	end;

	class Nurse = 
	   Display = "Display Nurse";
	   Pay     = "peanuts";
	end;

	class Orderly = 
	   Display = "Display Orderly";
	   Pay     = "peanut shells";
	end;

Here code is grouped by data.

- Easy to add new data: adminstrators, etc., but hard to add new operations like PayBonus or Promote.

Ingalls' Test for OOP-ness

Can you define a new kind of integer, put your new integers into rectangles, as the system to blacken a rectangle, and have everything work?

Essentially he is asking "Is everything an object in the language/system?" His test is the most extreme case. If integers are treated as objects by OS routines, then *everything* is an object.

Why would having everything be an object matter?

- Extensibility of programs---
If we want to add a new kind of data/operation/agent to program or change existing entitites and have new code work with existing code without modication, we need to treat entities abstractly.

Anything we treat as an object is only interacted with via message sends.

Hence it can be replaced with a very different object and things will still work as long as the new objects have all the necessary methods (or meet the necessary protocol in Smalltalk-ese).

What does this flexibility cost?
Cannot optimize:

x add y

to:

integer_add(x,y)

Big cost if program has a lot of integer operations.

Efficiency of Smalltalk: 5 to 10 * C.

What is a reasonable performance?

How should we measure the trade-off between programmer time and computer time?

Kathleen Fisher / kfisher@cs.stanford.edu