Objects, Classes, and Inheritance

Simple Objects

Why Objects Anyway?

Object-oriented programming doesn't fundamentally add much (it doesn't lead to much shorter programs)
But, it is a style more appropriate to human psychology.

Thesis: Humans as part of their basic function are highly adept at recognizing and interacting with everyday objects.

Everyday objects: Things we encounter everyday

Properties:

active: not fully controlled by us, with internal evolving state.
communicative: we can "send messages".
encapsulated: some of the properties are not visible (though we can learn some of it by sending messages)
nested: complex objects have many object components (which in turn have object components etc)
uniquely named (more or less)

Objects in OOP (Object-Oriented Programming) also have all of these features.

Conclusion: It is thus good to have programs create entities like these objects we are familiar with.

The structure of an object

An object is

Some encapsulated code (methods/operations) and mutable state (instances/fields)
--notice that objects are inherently non-functional as defined above
With a unique name (an object reference) to refer to it;
The methods should also be self-aware, aware of the name of the object it is a part of (accessed via this in Java/C++ and self in Smalltalk).
Objects should be polymorphic in the sense that a "fatter" object can always be passed to a method that needs a "thinner" one only (one with fewer methods).

Other aspects for objects We will come back to some of these later:

Classes
- Classes are an "add-on" idea and you can effectively make a language without any classes (e.g. Self).
- Topics to understand: new, inheritance, method override, access to overridden methods of the superclass, dynamic dispatch
Field/method information hiding: public/private/protected
Types and Modules
Overloading (syntactic sugar; skipped)

We will uncover these issues by encoding objects in the DSR language.

Encoding simple objects in DSR

Slogan: Objects are records of functions and refs

Record labels and values are slots for either methods or fields.
Slot with a Function represents a method
Slot with a Reference represents an instance/field

First pass at objects in DSR

Consider a point, with x, y fields and methods magnitude and iszero with obvious functionality.

point = { x = 4; y = 7; magnitude = Function _ -> ???; iszero = Function _ ->???}

magnitude needs access to x and y, but it currently has no name for them.
Solution: pass the object itself as argument when a method is invoked
(this also happens to be how C++ implements objects)

Object then is

point = { x = 3; y = 4;
          magnitude = Function this -> Function _ -> sqrt(this.x + this.y);
          iszero = Function this -> Function _ -> this.magnitude (this) = 0   
}

Message send then is

point.magnitude(point){}

Observations on the above.

the object point itself is passed as an argument to the message send.
zero is a method which calls magnitude -- we need to pass along this, which was originally passed to us, on the magnitude so it can know itself as well.
This encoding of self-reference is called the self-application encoding.
There are a number of other encodings possible, some we cover below.

We can write a message send abbreviation

obj <- method

which stands for

(obj.method) obj

Mutable Instance Variables

Problem: These objects are immutable!

The point coordinates can't change. This equals windows that can't resize, sets/stacks/queues... that can't have members added or deleted, etc.
It is good to have some fields immutable, but here we have all of them immutable: too much of a good thing.

Solution.

point = { x = Ref 3; y = Ref 4;
             magnitude = Function this -> Function _ -> sqrt(!(this.x) + !(this.y)),
             setx = Function this -> Function newx -> (this.x) := newx,
             sety = ... }

We can now say

point.setx (point)(0);
point.magnitude (point){}; (* returns 4 now, objects state changed *)
point.x := 6;              (* directly change fields *)
!(point.y)                 (* directly get field values *)

In general, this strategy gives a faithful encoding of simple objects.

Let us pause a bit and map some classic notions of object on to this paradigm. Consider encoding sets, stacks, students (as records in a database), etc.

Object Polymorphism

Object Polymorphism means an object passed to a method as an argument can be of a form different than the form declared (or in an untyped language, originally intended) in the method.

Example:

Suppose there is an abstract class Person with subclasses Mother, Father, Child.
A method
```
tallerThan(aPerson) =
      this <- height >= aPerson <- height
```
could be a method of a Person and is passed another Person as argument.
But, the method also will accept a Child, Mother, or Father since they all have a height.
The method is thus polymorphic -- many forms of object can be passed to it.

Observations

We already encountered this issue for the case of records:
```
Let grabsnork = Function r -> r.snork
```
can take any record with a snork field:
```
.. In grabsnork ({snork = 4, moo = 4, wapp = 44})
```

Object and record polymorphism is really the same thing, evidenced by how we view objects as records. So, using the above encoding of objects we can obtain object polymorphism.

Let eqpoint =
      { ... // all the code from point above: x,y,magnitude,...
       equal = Function this -> Function apoint -> !this.x=!apoint.x
                                                   And !this.y =!apoint.y}
      In eqpoint <- equal({x = Ref 3; y = Ref 7; /* anything else or nothing */})

--the "point" passed to equal need only have x and y.

Object polymorphism in our embedded OO langauge is thus more powerful than that of C++/Java:
- Java and C++ look to the inheritance hierarchy to see what is allowed: you can always pass a subclass to a method expecting a superclass object, but no other choices are possible.
- suppose Dinosaur objects also had a height method; a aPerson <-tallerThan(aDinosaur) would then execute without error.

Dispatch issues that arise with object polymorphism:

Since the form of object is not completely known (in our OO language, its very unknown because tallerThan could even get aDinosaur as argument!), we don't know precisely where the methods will be laid out in memory.
Thus, hashing will be required to look up methods.
This is exactly the same problem we encountered in our DSR compiler when we were compiling records. "Objects are records" again.

Private and protected Methods/Instances

(we skipped this topic in lecture)

We want to protect some methods/instances from direct outside use.

Aids in encapsulation of object data.
This is private/protected of C++/Java; in Smalltalk, no instance variables may directly be set by outsiders ("protected" in C++-speak).
For now we encode objects with hiding in DSR; for simple objects the relevant forms of hiding are private and public; protected makes sense only in the context of classes and inheritance.
In C++/Java, its really the type system / bytecode verifier that enforces privacy of data; for us we need to make it inaccessible since we have no type system.

A partial encoding of hiding in our DSR objects

Let point = ... In
Let hiddenPoint = { magnitude = point.magnitude point;
                        setx = point.setx point;
                        sety = point.sety point }

--each method is "pre-applied" to the full point, and the hiddenPoint only contains the public methods/instances. Methods are now invoked simply as

hiddenPoint.setx 5

This solution is somewhat flawed.
Methods that return this re-expose the hidden parts.

point = { x = Ref 3; y = Ref 4;
             magnitude = Function this -> Function _ -> sqrt(!(this.x) + !(this.y));
             setx = Function this -> Function newx -> (this.x) := newx;
             sety = ...;
             sneaky = Function this -> Function _ -> this }

Let hiddenPoint = {magnitude = point.magnitude point;
                       setx = point.setx point;
                       sety = point.sety point;
                       sneaky = point.sneaky point }

hiddenPoint.sneaky {}

now returns the full point object, oops!

A better solution In order to solve this problem we must use a different style of encoding, where we don't pass this evey time a method is invoked. Instead, the object gets a pointer to itself at the start.

Let prePoint =
  Function this -> Let privateThis = { x = Ref 3; y = Ref 4 } In
   { magnitude = Function _ -> sqrt(!(privateThis.x) + !(privateThis.y));
     setx = Function newx -> (privateThis.x) := newx;
     sety = Function newy -> (privateThis.y) := newy }
     notSneaky = Function _ -> this }
In Let point = prePoint prePoint // make the object self-aware forevermore.
In ...

and message send simply as

point.magnitude ()

Method notSneaky returns this, but it is the public parts of this only. Note, for this encoding to hide properly, you can only send messages to privateThis, not return it.

These encodings are relatively easy; encoding classes and typed objects as well is much more difficult.

Classes

Classes are foremost templates for creating new objects: an object factory.
Each object created from a class must have its own instance variables (exception: static fields, which we ignore now).
Simple class encoding, ignoring hiding.
Its trivial: freeze the object-building code so it can be repeatedly executed.

Let pointClass = Function _ ->
             { x = Ref 3; y = Ref 4;
               magnitude = Function this -> Function _ -> sqrt(!(this.x) + !(this.y));
               setx = Function this -> Function newx -> (this.x) := newx;
               sety = ... }
In ...

To create a new object of aClass, just thaw the above:

new aClass is defined as aClass ()

Then, some code like

Let point1 = pointClass () In point2 = pointClass () In point1.setx 5 ...

will create and use instances of pointClass.

point1 and point2 have their own x and y values.
This is good.
Its a product of how Ref gives you a fresh memory reference every time you use it.

Hiding in classes: apply above freeze trick to object encodings above -- also easy.

Inheritance

80% of the usefulness of object-oriented programming comes from the above concepts:

Objects that encapsulate both the code and data for some functionality under a single name,
Object polymorphism,
Templates for generating objects (one function of classes)

20% is the idea of

Inheritance

As you well know,

Inheritance allows related objects to be defined that share the same code.
The spirit of inheritance is "automatic re-cut-and-paste"
- Suppose ColorPoint inherits from Point
- This means you can imagine all the code from Point pasted into ColorPoint
- Furthermore, if you change Point, that change automatically gets reflected in the Point code pasted into ColorPoint

We can encode inheritance in DSR

Grab the fields/methods we need from a superclass object which we have created as our slave.
Every subclass object then is really two objects at run-time:
- superclass slave object;
- subclass object which contains new and overridden information only
Real OO languages tend not to implement things this way, for efficiency only however.

Example: ColorPoint class.

Let pointClass = ... as above ... In
Let colorPointClass = Function _ ->
          Let super = pointClass () (* create slave point "super" for our use *) In
             { x = super.x; y = super.y; (* grab these fields from slave *)
             color = Ref  { red = 45; green = 20; blue = 20 };
             magnitude =
                Function this -> Function _ -> super.magnitude this () *
                                   this.brightness this;
             brightness = Function this -> Function _ -> ... compute brightness  ...;
             setx = super.setx (* grab method from superclass slave *)
             sety = super.sety; setcolor = ... }
In ...

colorPointClass () will make an object with the appropriate methods.
The magnitude method has been overridden. Inside the new method, the old method ("super") can be invoked by
```
super.magnitude this ()
```
Note how in the above interpretation all of the inherited methods are explicitly listed by name. This is not the best form of encoding, but is as good as we can do in the current language: there is no operation to "tack on" fields to an arbitrary record, or to append two records.

Test code to think about to see if we believe the encoding above:

Let cp = colorPointClass () In
  cp.setx cp 5;
  cp.sety cp 5;
  cp.magnitude cp ()

Dynamic Dispatch

Methods are dynamically dispatched when its not clear from looking at a message send o.m in the code, precisely what method m will be run at run-time.

Dynamic dispatch is related to object polymorphism: a variable v could contain many different kinds of objects, so v.m could be sending m to one of those different kinds of objects and thus unless you know the object, you don't know which method is being run.
This term refers to how the method invoked by a message send is not fixed at compile time. If we had a method isNull in pointClass and inherited by ColorPointClass, with code
```
Function _ -> (this.magnitude this) = 0
```
the magnitude method performed here is not fixed at compile time: if this is a Point, the brightness is not taken into account, but it is if this is a ColorPoint. This is known as dynamic dispatch.

In Java (and every other object-oriented language), you always get appropriate dynamic dispatch. In C++, if you don't declare a function virtual, you get no dynamic dispatch.

Inheritance should model the cut-and-paste view of code, and if the method were pasted, the dispatch would change. This view is sound only if inherited methods get a revised notion of this upon inheritance.
Does our encoding promote dynamic dispatch?

Adding Object-Orientated Features to D: DOB

Now that we have given encodings for objects in terms of known syntax, we can study how these features may be directly added to the D language to give DOB, object-oriented D.

The alternative of not adding any new syntax and directly programming, is simply too confusing for the programmer (esp. after types are added!).
--For example, the encoded colorPointClass above is just too hard to read.

DOB has the following features

classes, message send, methods, instances, super, this
instance variables hidden (protected) and methods exposed (public), as in Smalltalk
primitive object definitions allowed

Primitive objects aren't very common in practice; here is why we include them.

If you want to write an interpreter for DOB, the value returned by "New aClass" is an Object.
Having primitive objects is a handy programming tool: a more lightweight object, also like blocks in Smalltalk and anonymous inner classes in Java.
With primitive objects you can get rid of functions entirely (though we don't do this).

Assertion: Object-oriented languages of the future should include syntax for primitive objects. Also gives much of advantage of higher-order functions to object-oriented language. Java's inner classes are about 95% there.

Here is the point/colorpoint example in DOB's concrete syntax.

Let pointClass =
      Class Extends EmptyClass
            Inst
              x = 3;
              y = 4
            Meth
             magnitude = Function _ -> sqrt(x + y);
             setx = Function newx -> x := newx;
             sety = ...
     
In Let colorPointClass =
      Class Extends pointClass 
            Inst
              x =  3;
              y =  4;
              color = Object Inst Meth red = 45; green = 20; blue = 20
            Meth
              magnitude =
                Function _ -> Super <- magnitude ()) *
                        This <- brightness;
              brightness = Function _ -> color <- red + color <- green + color <- blue;
              setx = Super <- setx (* explicitly inherit *)
              sety = ...; setcolor = ... 
     
In Let point = New pointClass 
In Let colorPoint = New colorPointClass In
  point <- magnitude(); point <- setx 4; colorpoint <- magnitude () 
End

This syntax is derived from the encoding of objects and classes above.

Points to be made about the DOB language syntax details:

This and Super are now "reserved variables": in the encoding "Function this -> ..." had to be explicitly written; that is implicit by having This a special variable.
In the encoding, we used one style of encoding for a base class and another style for a class inheriting from another class. Here we combine these into a single notion by having a superclass always specified, but allowing the superclass to be EmptyClass, an empty class.
DOB Instance variables use L/R value form of state: there is no need for ! to get the value when its used in an expression. Instance variables are thus mutable, not following the ML convention that all variables be immutable. Method arguments are still immutable in DOB. Since it is clear which variables are instances and which are not, there is no great potential for confusion. An advantage of this approach is it keeps instance variables from being directly manipulated by outsiders. The disadvantage is the L/R-value confusion we discussed when dealing with state.
There are thus two varieties of variable: immutable method/function parameters, and mutable instances. This corresponds to Smalltalk practice. Immutable instances can be considered methods (see the color Object in the example above).
Note how we still have to explicitly inherit methods. This is not the greatest syntax, but is needed for the translation since DSR records are not extensible.
method bodies are generally functions, but need not be; they can be any immutable, publicly available value.
There is no constructor function; following Smalltalk, initialization is done explicitly by writing an initialize method. Instance variables have to be given some initial value. A "better" implementation of the above classes would be as Function x -> Function y -> Class ... Inst x = x, y = y, ....

Here is the datatype for DOB.

datatype ide = Ide of string | This | Super (* this & super are special id's *)

datatype label = Lab of string

datatype term = (* ... insert D syntax elements here ... *)
| Object of ((label * term) list) * ((label * term) list) (* instances list and methods list *)
| Class of term * ((label * term) list) * ((label * term) list)
| EmptyClass | New of term
| Send of  term * label
| InstVar of label  (* parser has to decide if a var is InstVar or just Var *)
| InstSet of  label * term

The relation is mostly clear; the one perhaps tricky bit is InstSet(Lab"x",exp) is the abstract syntax for concrete syntax x := exp, and InstVar(Lab "x") corresponds to x for x an instance variable access.
Note that regular variables that are parameters to functions, such as newx above, are just Var (Ide "newx").

Translating DOB into DSR

The translation of DOB into DSR follows the ideas of the case-by-case informal encodings given above. Actual object-oriented compilers do not use this methodology now, but it is a valid one and is much more "methodological" and leads to a more understandable view of object-oriented language compilers.

This section: translate DOB into DSR via a function toDSR. By implementing this translation, writing a parser for the DOB syntax, and using your DSR compilers, a DOB compiler is obtained:

DOBCompile = toC o hoist o Atrans o cc o toDSR ;

where toC etc are the components of the DSR compiler.

The Official Translation

The DOB-to-DSR translation function is inductively defined as follows.

toDSR Object Inst x1 = e1, ..., xn = en Meth m1 = e1', ... mk = ek' =
   { inst = { x1 = Ref (toDSR e1); ....; xn = Ref (toDSR en) };
      meth =  { m1 = Function this -> toDSR e1'; ....; mk = Function this -> toDSR ek' } }
toDSR Class Extends e Inst x1 = e1, ..., xn = en Meth m1 = e1', ... mk = ek' =
   Function _ -> Let super = (toDSR e)() In 
    { inst = { x1 = Ref (toDSR e1); ....; xn = Ref (toDSR en) };
      meth =  { m1 = Function this -> toDSR e1'; ....; mk = Function this ->  toDSR ek' } }
    
toDSR New e      = (toDSR e) () 
toDSR EmptyClass = Function _ -> {} 
toDSR Super <- m =  super.meth.m this
toDSR e <- m  =  Let ob = (toDSR e) In ob.meth.m ob, for e not super
toDSR x := e     = this.inst.x := (toDSR e)  (* notice how the LHS is an instance x, not an arb. expression *)
toDSR x          = !(this.inst.x), for x an instance variable
toDSR y          = y, for y a function variable
toDSR <others>   = homomorphic

The translation is fairly clean except message sends to Super have to be handled slightly differently to give dynamic dispatch.

Instance variables x and method arguments y are different sorts in DOB: their translation is different.

As an exercise, feed the above point/colorpoint example through this translation. The code produced will be very similar to the initial informal translation given.
Note, officially f (), empty-argument function application, may be written f {} (empty record application), and _ in Function _ -> e is any variable not occurring in e.

A Direct Interpreter for DOB

(this topic will be skipped in lecture)

The idea of writing the interpreter is to use the encoding as a guide. We will blissfully ignore dealing with stuck states properly, by using incomplete pattern matches.

First, objects.

...
| eval(Object(meths,insts)) = Object(meths,evalInsts(insts))
...

and evalInsts l = (* evaluate the list of instances, return evaluated list *)

Message send

| eval(Send(term1,label)) =
  let val1 = eval(term1) in
  case val1 of Object(insts,meths) ->
     subst(selectMeth(meths,label),val1,This)

Classes (only considering the case now of an empty superclass)

fun e(Class(super,insts,meths)) = Class(super,insts,meths)
 |  e(New(Class(MTClass,insts,meths))) = eval(Object(insts,meths))

...

Important features we skipped

Typing

It is relatively easy to understand objects and classes in terms of records of Function's and Ref's. It is a lot harder to understand typed objects in terms of typed records of Function's and Ref's.

Typing objects will briefly be discussed later in the course.

Class Names

Classes in the above are not given unique names: the Class syntax has no field which is the class name. Pretty much every actual object-oriented language has a notion of class name which means something.

In Java, for instance, the class (and interface) names are important relative to casting: you can only cast an object to its super or sub-class.

Constructors and Destructors

In our language there is not so much need for constructors and destructors. Functions can return classes, and that method allows a form of constructor to be programmed:

Let Point = Function xinit -> Function yinit -> Class .... x = xinit, y = yinit, ...

Then, a new point (3,4) is created by

New (Point 3
4)

.
This is another advantage of having higher-order functions around.

Objects in OCaml

We briefly cover the OCaml object system: see The Manual.

Key features:

classes:

#class point =
   object 
     val mutable x = 0
     method get_x = x
     method move d = x <- x + d
   end;;
class point :
  object val mutable x : int method get_x : int method move : int -> unit end

for making classes (note the type says object)

new:
```
#let p = new point;;
val p : point = <obj>
```
point is an abbreviation for <get_x : int; move : int -> unit>

Using:

#p#get_x;;
- : int = 0
 
#p#move 3;;
- : unit = ()
 
#p#get_x;;
- : int = 3

Instead of constructors, you can define classes which take parameters upon new. In DOB this is like writing

Function init -> Class ....

Here is an example:

#class point x_init =
   object 
     val mutable x = x_init
     method get_x = x
     method get_offset = x - x_init
     method move d = x <- x + d 
   end;;
class point :
  int ->
  object
    val mutable x : int
    method get_offset : int
    method get_x : int
    method move : int -> unit
  end

"this" is an explicit parameter:

 class printable_point x_init =
   object (this)  (* declare variable this to refer to this *)
     val mutable x = x_init
     method get_x = x
     method move d = x <- x + d
     method print = print_int this#get_x 
   end;;

Inheritance is pretty much as usual; multiple inheritance is allowed.

 class colored_point x (c : string) =
   object 
     inherit point x
     val c = c
     method color = c
   end;;

virtual methods, private methods - skip.

Object polymorphism. This is one critical difference: there is no implicit object polymorphism in OCaml!
You must explicitly coerce e.g. a colorpoint to a point:

      #let colored_point_to_point cp = (cp : colored_point :> point);;
val colored_point_to_point : colored_point -> point = <fun>
 
#let p = new point 3 and q = new colored_point 4 "blue";;
val p : point = <obj>
val q : colored_point = <obj>
 
#let l = [p; (colored_point_to_point q)];;
val l : point list = [<obj>; <obj>]