CSE 130 Lecture Notes

CSE130 LECTURE NOTES

November 15, 1999

ADMINISTRATION

We're returning the second project today. The mean score is 67 out of 100, with a range of 19 to 98.

Reminder: Plagiarism will not be tolerated. One team copied many sentences from web pages without any acknowledgement. That team is getting zero for this project.

Several teams copied sentences from sources that they cited. If you do this, you must:

use quotation marks or indentation to indicate very clearly that someone else wrote this text, and
provide a citation immediately before or after the text that you copy.

Reminder: the lecture on Wednesday next week (before Thanksgiving) has been moved to Friday this week.

OOP KEYWORDS

(1) Object identity. Even if two objects have the same internal value, they are still different objects. Similarly, two variables are different even if temporarily they have the same value, because they have different locations, and hence in the future they can be updated differently.

Object identity is connected to an "object-centric" view of programming: every operation is about some primary object. Syntactically, every method has an unwritten (implicit) first argument, which is the object itself.

(2) Encapsulation. The state of an object is private to the object: the only way the state can be changed or observed is by calling one of the object's methods. This is what we called "implementation-hiding" before.

(3) Overloading. Two objects of different classes can have a method with the same name. If these methods perform conceptually similar operations, the caller of the method does not need to know the exact class of the called object. Overloading is particularly important with inheritance.

OWN VARIABLES REVISITED

Another point of view on objects is that an object is a single procedure with some variables that are global and private, i.e. they keep their values between calls to the procedure but they can only be updated inside the procedure. The methods of the object are alternative instructions that the object can execute.

According to this view, the object itself is really a dispatcher: it waits for a message and then selects one of its methods for execution based on which message was received. A class is a function that can generate new objects. For example:

type messages = (next, restart);
function newgenerator (initial:real) =
begin
    var seed: real := initial;
    return
        function (m: messages) =
        begin
            case m of
                next: seed := transform(seed);
                restart: seed := initial;
            end;
            return seed;
        end;
end;
function myrandom = newgenerator(1.2345);
function hisrandom = newgenerator(0.1428);

Here newgenerator is a higher-order function that returns another function, which is anonymous. Each returned function is a pseudo-random number generator (PRNG) that can respond to two alternative messages.

The updated PRNG seed is kept in the variable seed which is local to newgenerator so seed is fresh each time that newgenerator is called. However seed is global to the anonymous function so each version of seed keeps its value between calls to the corresponding individual PRNG.

ESCAPE COMMANDS: EXCEPTIONS

Let's think about the design of escape commands. In general a condition that makes an escape necessary is called an "exception". When an exception is triggered, and control escapes from inside a command, usually some recovery commands should be executed. Here are some desirable features of exception handling:

(0) The single entry, single exit property should be preserved: that control can only flow into the command at one point, and can only flow out at one point.

(1) It should be possible to raise exceptions and recover from them for any command, not just loops. There can be reasons to abort any command.

(2) When an exception is handled, it should be possible to execute some recovery commands as an alternative to the regular command which gave rise to the failure. For example if an exception is raised while reading an input value, it should be possible to recover by assigning a default value.

(3) It should be possible to provide exception handlers for many different types of exception.

(4) Providing exception handlers should be optional. If a handler is not provided, the exception should cause an escape from the enclosing block.

(5) Programmer-defined exceptions like "negative age" should be allowed in addition to system-defined exceptions like "division by zero".