Mathematical Foundations of Object Oriented Programming

I haven’t blogged about this before, but that doesn’t mean I haven’t given some serious thought to it. It just needs more serious thought.

The problem is Multimethods. Perl 6’s operator system is all based around multimethods. And the current multimethod thinking around the entire programming community gives me the heeby geebies, as Perl 6’s junctions did before I tore them to shreds for the greater good :-). I think I need to do precisely the same thing I did there: fall back to programming’s mathematical basis.

Whenever a programming feature strays far from mathematics, things start getting inconsistent and difficult to work with. Non-mathematical features tend to have major scaling problems. I don’t know why, I just know that it’s true. When the operator system of a large language is based on something, it had better be scalable.

I argue that the current conception of multimethods are far beyond “far from mathematics”. They are a travesty in its name; they wave math in math’s own face like a baby wielding a daggar. I’ll tell you the beginnings of my argument (my whole argument will appear in the paper I write describing this). I’d be appreciative to be pointed to any prior research in the area, as I’ve come across none.

First think of a class as the set of all (possible) instances of the class. Any method in a class C is a map with domain C. Now think of what inheritance means. If a class D inherits from a class B, then all objects in D are also objects in B. So D is a subset of B.

Now consider an inheritance heirarchy where B ⊂ A, C ⊂ A, and D ⊂ B. Take a moment to picture this. In the current conception of multimethods, they say that D is more derived than B. I can understand that, since D ⊂ B. But they also say that D is more derived than C. This is the flaw. To make matters worse, most methodologies (like Class::Multimethods) say that D is exactly twice as derived as C (from A). This is preposterous! Look at the definitions carefully. Could D have fifty elements and C have one? Sure. Could even C ⊂ D? Sure it could. All that we know is that C is a subset of A, and that D is a subset of A. There could be (and are) hundreds of classes between A and C. Just because we don’t name them doesn’t mean they don’t exist.

Here’s where it gets completely awful. Okay, so D is twice as derived as C from A. So let’s define the distance d(A, D) to be 2 and the distance d(A, C) to be 1. This is a reasonable thing to do if you’re going to say that first silly statement. Now, to resolve which map m in the set M to use, we add up each distance from parameter to argument positionally. So given a map J: A × B → X (X is not important) and a particular pair of arguments in the sets (C, D) for example, the distance from the map to the tuple is d(A,C) + d(B,D) = 1 + 1 = 2. We do this for every candidate map, and whichever one has the lowest sum distance is the one we call.

Do you see my point? We’ve taken the set-theoretical concept of classes, grafted on this idea of “order of derivation”, summed these together in an arbitrary fashion (tuple inner product with operators (d, +)), and used this as the measure of applicability. We’ve strayed far, far away from mathematics, only to come back to it at the end with a bunch of irrational defintions, and we claim that the result is “mathematical”. Highly dubious.

That’s the beginning. I’ll start my blog entry on the beginnings of my solution now. Stay tuned.


1 thought on “Mathematical Foundations of Object Oriented Programming

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s