Could you imagine any other way to have OO implemented than the classic class-based approach?

Question

I've lately been thinking a lot about alternatives to the class-based approach to object-orientation. One thing which bugs me in today's languages is that we often use static classes / singletons to design single (global) objects because there isn't any other way to do it, so in my opinion it's rather a hack than a feature. Another thing is that Java for instance allows the programmer to have enums with additional data (global state) and functionality which make them kind of object in my eyes, too.

Anyway, what I'd like to know is whether you have any ideas for a different approach to object-orientation in a compiled and efficient language (therefore, creating objects by prototyping is probably not a good idea) or, if you don't have any, whether there're things in the classic OO approach which bug you a lot, too.

[EDIT]: Just to make things clear. As indicated above I already know prototype-based programming.

Answer 1

Check out prototype-based programming.

Answer 2

Take a look at the Actor Model. It's something like classes except for being asynchronous. If each actor is a Finite-State-Machine, you would have a potentially powerful system.

Erlang uses something like that, I'm told... at least similar. The point with the actor model is that it doesn't need to be implemented purely, and so does not need to be part of Erlang.

I started a small language that used that model once a few years ago. I might try it again sometime.

Answer 3

I think you are having trouble defining the "classical OO" approach. Is the signal method in Objective-C classical or the static method in standard C++?

In functional languages, it's easy enough to have non-object functions that, in a sense, act like objects because they return functions whose implementations are opaque. For example, the following code in Scheme

(define (create-ball color)
    (lambda (attribute-name)
       (if (equal? attribute-name "color")
            color
            "method-not-supported"))))

will output a function which isn't officially an "object" but it can act like one since it stores state, but you're not very clear about what exactly is wrong with the object-oriented paradigms you have been exposed to.

Answer 4

Now that my flame retardent suit is safely secured, I can say it: I dislike OOP.

The central problem I have with it is that it tries to come up with a single taxonomy in which every unit of functionality truly belongs.

There are a couple of problems with this. First, producing a good taxonmy is hard. People suck at creating them. Secondly, I am not convinced that you can actually structure a sensible, maintainable, hierarchy that will withstand change in a project containing a lot of entities; the whole practice of refactoring is basically acknowledging the difficulty of creating large, all incompassing taxanomies.

Actually, I think that OOP is over-engineered. Everything you can do with OOP can be done with higher-order functions (HOFs). HOFs are much more elegant, much more flexible solution to the same problems that OOP tries to address.

So if you're asking of another way to do OOP style stuff, HOFs are probably the closest alternative technology that has a similiar level of flexibility.

Answer 5

take a deep look at javascript which has the prototype based model or check out lua which has a some strange way to implement object orientation

Answer 6

Take a look at CLOS, which is basically function/method based.

Answer 7

Google's Go language takes a decidedly different approach to object orientation, maybe worth a look.