CSC151.01 2014F, Class 53: Objects in Scheme
============================================

* Choose your own location for today and tomorrow.  Please plan to preserve
  your position tomorrow (we'll be doing a two-day lab).

_Overview_

* Preliminaries.
    * Admin.
    * Upcoming Work.
    * Extra Credit.
    * Question on the Exam.
    * Other Questions.
* Preparation.
* Lab.

Preliminaries
-------------

### Admin

* Plan for the last week of the semester:
    * Monday/Tuesday: Objects in Scheme
    * Wednesday: Debriefing, Phase 1
    * Friday: Debriefing, Phase 2; Evaluations; Exam grades returned
* Information on the final to be distributed tomorrow.

### Upcoming Work

* Exam 4 due TONIGHT at 10:30 p.m. in electronic form!
    * Printed version due in class tomorrow.
    * Epilogue due tomorrow night.
* Reading for Tuesday:
  [Objects in Scheme](../readings/objects-reading.html)
* No lab write-up for today (or tomorrow).  

### Extra Credit Opportunities

#### Academic

* Inside Grinnell Thursday the 11th at noon in JRC 101: Grinnell's 
  Endowment: What Can and Can't it Do?

#### Peer Support

* Karan's radio show 11pm Thursday nights on KDIC 
* Evan's radio show 5pm Friday nights on KDIC
* Donna's radio show Sunday midnight on KDIC
* Jazz Band, Dec. 13, 8pm Gardner

### Exam Questions

### Other Questions

Preparation
-----------

Four minutes with your partner:

* Look over the self-checks
* Main conceptual points of the reading
* Main programming points of the reading
* Murkiness
* How long should Sam spend rambling?

Main Conceptual Points

* Objects group data and procedures.
* Objects *encapsulate* - they protect the internal representation
* We send objects messages to obtain data.
* We send objects messages to change their state.

Implement Objects in Scheme

* Functions are the center of Scheme, so we build functions that
  represent the objects.  (We generally can't look inside procedures.)
* The function takes the message as a parameter and uses a cond to
  choose what to do depending on the messasge.

        (define object
          (let ([state (vector "Hello" 5)])
            (lambda (message)
              (cond 
                [(equal? message ':do-this)
                 (do-what-was-asked)]
                ...
                [(else (error "I do not know how to" message))))))

* We often use the last clause of the cond to report an unknown message.
* Since objects are mutable, we store the "state" of an object in a
  vector.

Murkiness

* Why did you just move the let outside the lambda?
   * If it's within the lambda, it gets redefined every time you ask
     the object to do something, so the state is not preserved.
* What's do you mean by "objects of the same type" (vs objects of
  different types)?
    * Practice: We often have a `':type` message that indicates
      the type of the object
    * Conceptual: Do we think about them the same or different
    * Beyond this class: We think about them in terms of them
      messages it responds to.
* Explain the difference between the switch object and the switch
  constructor.

Let's see ...

   (define switch0
     (let ([state (vector #f)])
       (lambda (message)
         (cond 
           [(eq? message ':get-position)
            (if (vector-ref state 0) 'on 'off)]
           [(eq? message ':toggle!)
            (vector-set! state 0 (not (vector-ref state 0)))]
           [else 
            (error "switch: unrecognized message" message)]))))

But we might want more switches, so ...

   (define switch1
     (let ([state (vector #f)])
       (lambda (message)
         (cond 
           [(eq? message ':get-position)
            (if (vector-ref state 0) 'on 'off)]
           [(eq? message ':toggle!)
            (vector-set! state 0 (not (vector-ref state 0)))]
           [else 
            (error "switch: unrecognized message" message)]))))

   (define switch2
     (let ([state (vector #f)])
       (lambda (message)
         (cond 
           [(eq? message ':get-position)
            (if (vector-ref state 0) 'on 'off)]
           [(eq? message ':toggle!)
            (vector-set! state 0 (not (vector-ref state 0)))]
           [else 
         (error "switch: unrecognized message" message)]))))
   
Policy: When you are writing nearly-identical procedures, write a 
higher-order procedure instead.  (More generally, factor out common code.)

Once we've defined make-switch, we can intead write

    (define switch0 (make-switch))
    (define switch1 (make-switch))
    (define switch2 (make-switch))

Lab
---