\documentclass[twocolumn]{article}

\usepackage{fullpage}
\usepackage{palatino}

\begin{document}

\title{6.001 Tutorial 10}
\author{David Ziegler}
\date{November 15, 2004}
\maketitle

\section{Administrivia}
\begin{itemize}
\item Problem set 8 is due tomorrow.
\item Project 4 is due Friday.  Please remember to send me an email
  with the details of your extension to the system by 6:00 on
  Wednesday!  Also, it will almost certainly \emph{not} work in other
  Scheme implementations --- use MIT Scheme!
\end{itemize}

\section{Object-Oriented Programming}

\subsection{The High Level}
Another ``paradigm'' for thinking about programming (like ``functional
programming'' or ``imperative programming'').  Not necessarily better,
just different.  The idea is to combine the data and the operations
performed on that data into one blob.  Then, all the data and
operations are combined, which makes extending the system easier later
on.

In \emph{our} object-oriented system, the implementation is based on
\emph{messages}.  To request that an object does something, you send
it a message by applying the object to a symbol,
e.g. \verb+(car 'park)+.  This returns a \emph{method}, which actually
does the computation you're interested in.  You apply the method to
the arguments, e.g. \verb+((car 'park) 'carefully)+.

In our system, we have \verb+make-foo+ and \verb+create-foo+
procedures.  The \verb+make+ procedure defines how the object works
--- the methods it has, the state variables that are part of the
object.  The \verb+create+ procedure builds an instance of the object
--- an actual piece of data that is that type of object.

Objects have the nice property that they can \emph{inherit} from other
objects.  For example, a \verb+book+ is a \verb+mobile-thing+, which
is a \verb+named-object+, which is a \verb+root-object+.  By
inheriting, you can define new objects that have different behaviors,
but only write a small bit of code.

\subsection{The Low Level}
An object is a procedure and the environment associated with it.  The
procedure takes a message (symbol) and returns a procedure that ``does
the right thing.''  The environment associated with the procedure
contains all the state of the object --- whatever fields the object
contains.

When a procedure is \verb+create+d, an \verb+instance+ is built for
it.  This object just takes a message and passes it to the handler.
The \verb+instance+'s handler is set to be the result of
\verb+make-foo+.  If the object has an install method, it is called.

The point of all this is to have one piece of data that represents the
object itself --- the \verb+instance+ \emph{is} the object.  The
handler can be changed later.  When the object is created, the
\verb+make+ procedure is called with the \verb+instance+ as
\verb+self+.

\section{Carry Cdr}
Assuming that \verb+the-floor+ and \verb+my-desk+ are container
objects, which we can draw as clouds, what does the environment
diagram look like as a result of this?

\begin{verbatim}
(define spell-book
  (create-mobile-thing 'spell-book
                       the-floor))
\end{verbatim}

Next, we evaluate the following.  What happens?

\begin{verbatim}
(ask book 'change-location my-desk)
\end{verbatim}

\clearpage
\onecolumn

\section{Appliances}

First, we're going to create an \verb+appliance+ class.  Appliances
can be either on or off, and they have a fuse that can blow if they
draw too much current.  As an example:

\begin{verbatim}
(define washing-machine (create-appliance))
(ask washing-machine 'on?) ; #f
(ask washing-machine 'switch 'on)
(ask washing-machine 'on?) ; #t
(ask washing-machine 'blow-fuse)
Bang!  Fuse blew!
(ask washing-machine 'on?) ; #f
(ask washing-machine 'switch 'on)
(ask washing-machine 'on?) ; #f

(define (make-appliance self)
  (let ((switch-state 'off)
        (fuse-blown #f)
        (root-part (make-root-object self)))
    (make-handler 'appliance
                  (make-methods













                   )
                  root-part)))
\end{verbatim}

\clearpage

Now we add new appliance types --- a \verb+blender+ and a \verb+tv+.
A blendar is just like an appliance, but it also has a speed.  A
\verb+tv+ is an appliance that also has a channel.

\begin{verbatim}
(define cuisinart (create-blender))
(ask cuisinart 'set-speed 5)
(ask cuisinart 'speed) ; 5
(ask cuisinart 'on?) ; #f

(define (make-blender self)
  (let ((speed 0)
        (appliance-part (make-appliance self)))
    (make-handler 'blender
                  (make-methods










                   )
                  appliance-part)))


(define sony (create-tv))
(ask sony 'set-channel 7)
(ask sony 'channel) ; 7
(ask sony 'on?) ; #f

(define (make-tv self)
  (let ((channel 0)
        (appliance-part (make-appliance self)))
    (make-handler 'tv
                  (make-methods










                   )
                  appliance-part)))
\end{verbatim}

\clearpage

We realize that lots of people like to watch TV while they cook, and
we begin to offer a combination tv/blender (\verb+bleevee+) appliance
--- it chops, it dices, it changes channels!  The problem is that our
fuses are cheap, and if the blender speed goes above 3 while both the
tv and blender are on, both fuses blow.

The bleevee should support the messages \verb+blow-if-overload+,
\verb+switch+, and \verb+set-speed+, and inherit methods from the tv
and blender as appropriate.

\begin{verbatim}
(define (make-bleevee self)
  (let ((blender-part (make-blender self))
        (tv-part (make-tv self)))
    (make-handler 'bleevee
                  (make-methods















                   )
                  blender-part
                  tv-part)))
\end{verbatim}

\end{document}