Modularity & Objects

We'll extend FL with a simple object system. We add objects to the syntax as follows (new constructs are boxed):

We add object literals with the object ... end syntax and method calls. Objects are quite similar in appearance to records, and we'll see that we can describe the semantics of objects with a lightweight desugaring into records. In particular, the object literal syntax will desugar into record literals and method calls will desugar into record field accesses.

Here's an example program that creates a 2D point object for the point \((1, 2)\).

The dist method returns the squared Euclidean distance between this point and another. The semantics of self are similar to Python—each method takes self as its first parameter, and self is bound to the object. These objects only have methods—no fields—but that won't turn out to be a major limitation. The methods of the current object can be accessed using the # syntax on self.

We illustrate the semantics of objects by desugaring this example into a regular record:

In this desugaring:

• An object is just a record where each field in the record is a function that takes the object instance as its first parameter.
• Method calls are syntactic sugar for field access, as follows: \[ \call{x}{f} \rightsquigarrow x \proj f\ x \]
• Self-reference is facilitated by passing the object itself as the first parameter to every method call.

• what if we want to change the object?
  • return a new object that reflects the changes
  • (we can also add & use ref cells, but it's useful to think about the pure functional case first)
• we need a new record primitive
  • we'll need it later for inheritance anyway
• \(e\ \mathsf{override}\ e'\) — if e and e' both produce a record, then the overridden record prefers the fields in e to the fields in e'
• using override, we can write a method that returns a new object, modifying some of its fields

We make override more object-flavored by calling it inherit and including it in the object syntax.

Using this syntax, we can rewrite the previous program as:

Python implementation:

def call(obj, method, *args):
    return obj[method](obj, *args)

def override(r1, r2):
    r3 = r2.copy()
    r3.update(r1)
    return r3

point = {
    'x': lambda self: 0,
    'y': lambda self: 1,
    'shift': lambda self, dx, dy: override({ 'x': lambda _: call(self, 'x') + dx,
					'y': lambda _: call(self, 'y') + dy },
				      self),
    'dist': lambda self, p: (call(self, 'x') - call(p, 'x')) ** 2 + (call(self, 'y') - call(p, 'y')) ** 2
}

print(call(point, 'dist', call(point, 'shift', 4, 5)))

• we described the 'self' parameter as a way to access the methods of the current object, but that undersells its power
• we can modify methods that are defined in a superclass and have the modifications used by other methods that we didn't touch

def call(obj, method, *args):
    return obj[method](obj, *args)

def override(r1, r2):
    r3 = r2.copy()
    r3.update(r1)
    return r3

point = {
    'x': lambda self: 0,
    'y': lambda self: 1,
    'shift': lambda self, dx, dy: override({ 'x': lambda _: call(self, 'x') + dx,
					'y': lambda _: call(self, 'y') + dy },
				      self),
    'dist': lambda self, p: (call(self, 'x') - call(p, 'x')) ** 2 + (call(self, 'y') - call(p, 'y')) ** 2
}

x_counter = 0
def access_x():
    global x_counter
    x_counter += 1
    return 0

access_point = override({ 'x': lambda self: access_x() }, point)

call(access_point, 'dist', call(access_point, 'shift', 4, 5))
print(x_counter)

• a key feature of object-oriented languages is the ability to share code between different objects
  • programming by differences—describe one class of objects in terms of the difference from another class
• what does inheritance look like in real languages?
  • two broad categories
  • class-based inheritance
    • so far we've only looked at the behavior of bare objects
    • most oop languages actually don't have bare objects like this
    • instead, objects are instances of a class of objects
      • the class determines which methods the individual objects can have
      • inheritance operates on a class level
    • in our setting, classes are really just templates for generating objects—i.e. functions that return objects
  • prototype inheritance
    • create new objects by copying and modifying an existing object
    • this is essentially how our encoding already works
    • we can write "constructor functions" that work a bit like a class, but we can also inherit directly from other objects
  • why is class-based inheritance used at all?
    • this record override construct is actually quite difficult to implement efficiently
    • we can end up with objects that have a wide variety of shapes at runtime
    • looking up a method in an object of arbitrary shape might require a hash table or similar
    • if we know the shape of the object, we can just look at a specific offset
      • but this gets complicated with inheritance, so there still ends up being a hashtable lookup or similar to deal with looking up methods on parent objects

This roughly encodes a 2D point class:

All it does is create point objects given some \(x, y\). Inheritance in this encoding looks like a function call: