What makes a language Object-Oriented?

Question

Since debate without meaningful terms is meaningless, I figured I would point at the elephant in the room and ask: What exactly makes a language \"object-oriented\"? I\'m no

Answer 1

Definitions for Object-Orientation are of course a huge can of worms, but here are my 2 cents:

To me, Object-Orientation is all about objects that collaborate by sending messages. That is, to me, the single most important trait of an object-oriented language.

If I had to put up an ordered list of all the features that an object-oriented language must have, it would look like this:

1. Objects sending messages to other objects
2. Everything is an Object
3. Late Binding
4. Subtype Polymorphism
5. Inheritance or something similarly expressive, like Delegation
6. Encapsulation
7. Information Hiding
8. Abstraction

Obviously, this list is very controversial, since it excludes a great variety of languages that are widely regarded as object-oriented, such as Java, C# and C++, all of which violate points 1, 2 and 3. However, there is no doubt that those languages allow for object-oriented programming (but so does C) and even facilitate it (which C doesn't). So, I have come to call languages that satisfy those requirements "purely object-oriented".

As archetypical object-oriented languages I would name Self and Newspeak.

Both satisfy the above-mentioned requirements. Both are inspired by and successors to Smalltalk, and both actually manage to be "more OO" in some sense. The things that I like about Self and Newspeak are that both take the message sending paradigm to the extreme (Newspeak even more so than Self).

In Newspeak, everything is a message send. There are no instance variables, no fields, no attributes, no constants, no class names. They are all emulated by using getters and setters.

In Self, there are no classes, only objects. This emphasizes, what OO is really about: objects, not classes.

Answer 2

Supports classes, methods, attributes, encapsulation, data hiding, inheritance, polymorphism, abstraction...?

Answer 3

According to Booch, the following elements: Major:

• Abstraction
• Encapsulation
• Modularity
• Hierarchy (Inheritance)

Minor:

• Typing
• Concurrency
• Persistence

Answer 4

It's not really the languages that are OO, it's the code.

It is possible to write object-oriented C code (with structs and even function pointer members, if you wish) and I have seen some pretty good examples of it. (Quake 2/3 SDK comes to mind.) It is also definitely possible to write procedural (i.e. non-OO) code in C++.

Given that, I'd say it's the language's support for writing good OO code that makes it an "Object Oriented Language." I would never bother with using function pointer members in structs in C, for example, for what would be ordinary member functions; therefore I will say that C is not an OO language.

(Expanding on this, one could say that Python is not object oriented, either, with the mandatory "self" reference on every step and constructors called init, whatnot; but that's a Religious Discussion.)

Answer 5

Smalltalk is usually considered the archetypal OO language, although Simula is often cited as the first OO language.

Current OO languages can be loosely categorized by which language they borrow the most concepts from:

• Smalltalk-like: Ruby, Objective-C
• Simula-like: C++, Object Pascal, Java, C#

Answer 6

In my experience, languages are not object-oriented, code is.

A few years ago I was writing a suite of programs in AppleScript, which doesn't really enforce any object-oriented features, when I started to grok OO. It's clumsy to write Objects in AppleScript, although it is possible to create classes, constructors, and so forth if you take the time to figure out how.

The language was the correct language for the domain: getting different programs on the Macintosh to work together to accomplish some automatic tasks based on input files. Taking the trouble to self-enforce an object-oriented style was the correct programming choice because it resulted in code that was easier to trouble-shoot, test, and understand.

The feature that I noticed the most in changing that code over from procedural to OO was encapsulation: both of properties and method calls.