# MFOOP, Part Two

I decided just to start my paper instead of blogging about what I’m going to write about. Now I’m going to blog about some of the issues that the paper has brought up.

There’s a really neat thing that happened during the abstraction process. Remember those awful theoretical CS problems in which you’re trying to figure out whether Circle is derived from Ellipse or vice versa, and eventually you decide that they have to be siblings? That solution never seemed right to me. It’s one or the other, darn it!

The reason a Circle is not a kind of Ellipse is because you could treat it as an Ellipse and change it’s primary axis, deeming it no longer a Circle. But this doesn’t happen when the Circle is constant, because you can’t change it, and it works in every way like a constant Ellipse.

So—what if every object in the universe were constant? No, that doesn’t mean we’re in a pure functional language. You could still change objects, except you wouldn’t be changing them, you’d be mapping them to new objects. If this is the case, then a subclass is isomorphic to a subset, which is isomorphic to a subtype. No more subtle distinctions; they’re all the same thing. The set of circles is a subset of the set of ellipses, therefore, Circle is derived from Ellipse.

This is just a change in our way of thinking, and doesn’t effect language semantics. But it turns out to be a very useful change. All of those evil object design problems just vanish when you start to think of things this way. Another example is, in Perl, numbers and strings convert to each other. There was a big discussion on perl6-language about whether Num was derived from Str, or whether they were siblings, or what. With this mindset, it’s simple: Num is derived from Str. All numbers are strings. Some strings can be numbers. They don’t convert; they just are.

This is what the paper is about. It’s about some of the more subtle problems that arise when you start to think of things this way, what you need to do to fit it into what we call Perl, and what Perl needs to do to fit into this. I am confident that Perl will become a much more logically consistent language as a result, without losing its natural linguistic properties.

I still haven’t figured out what this means for multimethods. All I know is that we can’t define “distance” in that horrible way I wrote about last week, since there’s no concept of “existance”—everything that could exist does exist.