Let’s return to those $60/hr words and see how they describe different aspects of first-class namespaces. First, it’s fairly easy to see how namespaces provide encapsulation. It’s actually the defining feature of a namespace. That is, a namespace is a collection of variable (and function) names. Contrary to many common beliefs, encapsulation is not a new concept invented by OOP. C has structs, Pascal has records, and Lisp has closures.

OOP namespaces really break away from “classical” namespaces in that they have dynamic scope. That is, not only do they inherit the static lexical scope of the enclosing code, they can also inherit variables from any other arbitrary namespace, nee object. With some OOP languages, this inheritance can even be dynamically modified at runtime.

Lastly, polymorphism is the big daddy of OOP where everything else comes together. Let’s look at the prototypical OOP expression, “shape.area()”, to see what’s happening from a namespace point of view. The expression takes the namespace bound to the variable “shape”, looks in it for the first function named “area” and then evaluates that function in the scope of the namespace. There is one important point in that description: the area() function is evaluated in the scope of the “shape” namespace. If, say, the area() function references a variable named “radius”, that variable is looked up in the “shape” namespace, not the one in which area() was defined. Once you understand how this works, you understand OOP.

Now that we have the basic quantum mechanics of OOP, let’s circle back to the original question of why functional languages typically don’t use it. I think the most fundamental reason is that functional programmers don’t like the spooky action at a distance that can happen with dynamic namespaces. Functional programmers love their lexical closures. They can see at a glance all the variables names that are in scope and what’s being assigned to them. There is no unknown state. In the cases were OOP is introduced into functional programming, therefore, they will likely employ the idiom of Python and OCaml whereby the namespace is explicitly passed as a parameter to the function, rather than the conventional method whereby the function is surreptitiously evaluated in a different namespace.

class Circle extends Shape {
    public double radius() { 
        // Default to a unit circle.
        return 1; 
    }
    public double area() {
        return Math.PI * radius() * radius();
    }
}
class LargeCircle extends Circle {
    public double radius() { return 1000; }
}

abstract class ExtrudedShape implements Shape,Volume {
    protected double length;
    public double volume() { return length * area(); }
}
class Cylinder extends ExtrudedShape {
    protected double radius;
    public double area() {
        return Math.PI * radius * radius;
    }
}
class Box extends ExtrudedShape {
    protected double width;
    protected double height;
    public double area() {
        return width * height;
    }
}

; One possible way to define a constructor
; Returns a closure that contains x, double, and add-double
(define (obj-constructor x)
   (define (double y) (+ y y))
   (define (add-double y) (+ x (double y)))
   (this))
; Create an "object" and invoke add-double
(define obj-5 (obj-constructor 5))
(with obj-5 () (add-double 3))
; Should return 5+(3+3) = 11

; One possible way to "subclass"
; Redifine 'double' to always return 0
(define (sub-obj-constructor x)
   (with (obj-constructor x) ()
      (define (double y) 0)
      (this)))
; Invoke add-double on subclassed object
(define sub-obj-6 (sub-obj-constructor 6))
(with sub-obj-6 () (add-double 11))  
; Should return 6+0 = 6

; We can polymorph values as well as functions
(define obj-3 (with obj-5 ((x 3)) (this)))
; The value for 'x' in the obj-3 closure is now 3
(with obj-3 () (add-double 4))
; Should return 3+(4+4) = 11

; Totally screw with polymorphism by redefining add
(define obj-5-bad-add (with obj-5 ((+ *)) (this)))
(with obj-5-bad-add () (add-double 2))
; Should return 5*(2*2) = 20