Object-orientation should be EVEN, motherfucker!

Posted by: n2liquid on: November 25, 2011

• In: Chii Language | Chii's Design | Idea Snippet | Main | Object-Orientation
• 1 Comment

Quick, what was the most important driving motivation behind object-orientation? Yeah, you got that right; it was that of creating a 1:1 relationship between software and the real-world problem-universe it had to deal with (I’m sure you knew this; if not, I’m not sure you’ll be much impressed with the rest of this post).

The big idea was that objects would map to real-world “things” (and classes would map to the concepts behind those things).

Crystal.

At first, it looks like object-orientation in languages like C++ and Java do this mapping really well. For example, you have “Car” classes representing what a car is (concept), and “Car”-type variables representing the different cars in your application (individual instances). That applies for anything: clients, bank accounts, users, blog posts, and so on.

Marvelous, ain’t it?

Kitsu Chiri burying Java engineers

I could go on on how interesting inheritance and subtype polymorphism is, and what expressiveness possibilities they grant to developers, but I don’t have much time, so let’s get straight to the point of this post:

Object-orientation as it is fails miserably to express many simple real-world systems because it is not thorough enough — it’s uneven.

Although we have means to outline concepts and instances, our ability to imbue their relationships in code is very limited. Inheritance isn’t a catch-all solution to describe relationships between objects like classes and objects are to package real-world stuff. Far!

Things can have different uses for different users. That’s why I came up with the users () specifier. With it, you can express in plain source-code that only Game Masters can kick or ban Players, for example. You get language support for that kind of thing.

There is another family of similar relationships that I’d like to see getting language support too, though.

Let’s keep the Game Master vs. Player example. Game masters are game masters no matter how you look at them. The same applies for players. But what about relative concepts? Two players can be friends and share a special API for friendly interactions. It’s like they implement a special interface (“Friend”), but only between themselves; only in-private.

Those relative concepts can currently be expressed in C++ by means of protected and private inheritance, but most people wouldn’t understand it because, at least as far as I know, the original intent of non-public inheritance wasn’t that of supporting this kind of thing.

C++’s protected and private inheritance usage “should not be seen as an IS-A relationship, but rather a HAS-A relationship“. As I see it, private inheritance can be used to build IS-A relationships. Private IS-A relationships, that is:

If I have a Friend reference to a Player called David, David IS-A friend for me. This isn’t composition, guys! I’ll call it a private relationship from here on.

Well, actually this is all a matter of how you see things: one could argue that David HAS-A Friend-type handle that it can let some others access. In fact, this is the correct interpretation of my example in the C++ world. But the point is, C++ has a feature that can be bended to make something useful (as I see it), and I wish I could have such a similar feature that allowed me to build private relationships without bending anything.

Another problem with the use of private inheritance to do this is that friends may not be friends forever (aah, the finity of all human things; that’s so sad).

How can you ensure that, once a friendship is broken in game, that’s reflected in code? Sure, you can write code to release the Friend handle, but that’s artificial: we want software to truly reflect our systems without us having to explicitly check stuff like we do today in Java, C++, and pretty much any other language.

Key here is that those languages widely are imperative, but their object-orientation constructs are declarative, and that’s what makes their expressiveness shine compared to languages like C. I want to extend object-orientation, as the largely useful declarative construct it is to map software to real-world systems, pushing it closer to those noble original intents, by declaratively covering a wider range of real-world relationships in software.

I think I’ve outlined an interesting solution to part of the problem in Public, Protected, Private, and Beyond, but unfortunately I’m quite clueless as to how to do the same with the private relationships I explained above. I’ll get back to this in a future post.

Hoping you’ve enjoyed the read. And always remember: Chiri doesn’t like uneven OOP/OOD and will react accordingly.