Ingalls' Tape
Smalltalk Introduction
- Developed Xerox PARC, 1970-80
- Based on Simula
- added encapsulation
- private (C++ protected) instance variables
- public methods
- extended and refined object metaphor
- everything is an object (even classes)
- all operations are "messages to objects".
- Inspiration: Alan Kay's Dynabook
- - essentially a laptop
- - not considered realisitic in 1970's, 80's
- - reality in 1990's
- - idea 25 years ahead of hardware.
- - Smalltalk intended as language/os for dynabook
- - Smalltalk: design clean, flexible language without
worrying too much about performance. Feeling that the
hardware will catch up.
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