What is meant by the term "true" object orientation

Question

I have been hearing a lot about Ruby and possibly even Javascript being "true" object oriented languages as opposed to C++ and C# which are class oriented (or template based) languages. What is meant by true OO and what are the advantages of this over the class/template approach?

Answer 1

Not sure about the distinction you're after from the examples provided. But I do know what it isn't! When OO is bolted on to a language as an afterthought, e.g. Perl OO.

Answer 2

The C++ issue is the following. C++ classes exist only in the source syntax. There's no run-time class object with attributes and methods.

In Python, everything's an object. An object's class is another object, with it's own methods and attributes. This is true of the smalltalk environment, also, which is a kind of benchmark of object-orientation.

I think the "true" object-orientation refers to those environments where everything's an object.

[Java falls short of this because it has primitive types.]

Answer 3

I think it may be referring to Prototype Based Programming, a Programming Paradigm in which:

Classes are not present, and behavior reuse (known as inheritance in class-based languages) is performed via a process of cloning existing objects that serve as prototypes. This model can also be known as class-less, prototype-oriented or instance-based programming.

See also Ruby singleton methods.

Answer 4

A "True" or "Pure" object oriented language usually refers to languages in which everything is a first-class object including primitive types. In C++ and Java for example, the primitive types int, char, etc. are not objects. In Ruby, for example, everything is a object. Sometimes additional criteria are implied with the definition depending on who you are talking to.

Answer 5

It's a subjective term used to promote languages. I've seen it used to say C# and Java are true object oriented languages in comparison to C++ because everything must be in a class (no global functions or variables) and all objects inherit from one Object class.

For Ruby, it may refers to how Ruby treats everything as an object, so you could write 1.to_s, instead of something like str(1) or String.valueOf(1). This is because Ruby makes no distinction between value and reference variables. In Javascript there are no classes and you just create extensible objects that could be cloned for reuse, this style of programming is known as Prototype-based programming.

C++ on the other hand is advertised as a multi-paradigm language that allows you to use several approaches such as object-oriented, generic and procedural programming. It doesn't stick to one paradigm.

But yeah, it's just a subjective term that could mean anything. Generally it refers to whether the language puts more emphasis on objects as opposed to other language elements like functions, templates, etc. Wikipedia's article on SmallTalk calls it a 'pure' object oriented language, and the description applies to Ruby as well:

Smalltalk is a 'pure' OO language, meaning that, unlike Java and C++, there is no difference between values which are objects and values which are primitive types. In Smalltalk, primitive values such as integers, booleans and characters are also objects, in the sense that they are instances of corresponding classes, and operations on them are invoked by sending messages. A programmer can change the classes that implement primitive values, so that new behavior can be defined for their instances--for example, to implement new control structures--or even so that their existing behavior will be changed. This fact is summarised in the commonly heard phrase "In Smalltalk everything is an object" (which would more accurately be expressed as "all values are objects", as variables aren't).

Answer 6

Another interpretation of that term "true object orientation" is, that you can take some language that doesn't support OOP on its own, and stick an OOP way of doing things on-top of it. For example you can model encapsulation in C like

typedef struct foo_ {
    T1 (*getA)(foo * self);
    void (*setA)(foo * self, T1 a_);

/* private: */
    T1 a_;
} foo;

T1 foo_getA(foo * self) {
    return self->a_;
}

void foo_setA(foo * self, T1 a_) {
    self->a_ = a_;
}

foo * foo_create() {
    foo * f = malloc(sizeof(foo));
    f->getA = foo_getA;
    f->setA = foo_setA;
    return f;
}

void foo_destroy(foo * f) {
    free (f);
}

void doSomething(T1 a) {
    foo * f = foo_create();
    f->setA(f, a);
    foo_destroy(f);
}

Techniques for implementing inheritance and polymorphism has been in use a long time. One example is the GObject framework used as a basis for gtk+.

Now, while you can program in an object oriented manner, C doesn't support object orientation, but merely allows you to simulate it up to some degree. So you don't have true object orientation. Looking at C++/Java/C#, you have support for all these kinds of things like inheritance/data encapsulation and stuff first hand.

Answer 7

The C++ issue is the following. C++ classes exist only in the source syntax. There's no run-time class object with attributes and methods.

Of course, by that rule there is no such thing as object oriented programming on a conventional machine architecture, since there is no run time class object with attributes and methods at the machine-code level. (Or, at least, there isn't except for specialized architectures like the old System/38 or AS/400.)

What "object oriented" means was settled long ago as being three things: abstract data types, with inheritance, and polymorphism. (The Wikipedia article linked confuses the properties of OO with the benefits to some extent. But the important distinction is between OO and "object based" systems.)

Generally, what "X isn't really object oriented, unlike Y" really means is "I'm trying to sell you Y."

Answer 8

The term "true object-orientation" has the same meaning as the unadorned term "object-orientation".

When adding the qualifier "true" to "the subject at hand", one is attempting to alert the reader to the presence, within the current universe of discourse, of one or more "incomplete imitations" of said subject, which are being used interchangeably, but which, compared to the subject, lack one or more properties of significance to the discourse.

Such use should normally be followed by a description of the subject's properties, or a description of properties missing in the "imitation subject", or both; thereby leading the reader to understand, or at least contemplate, the distinction(s).

Object-orientation, as used by the person who coined the phrase, seems to include the following properties:

• Encapsulation of (data + behavior) into (objects) communicating via (messages) alone.
• Automatic reclamation of the memory used to represent (objects),
  when said (objects) are no longer referenced.
• Delayed binding of (meaning) onto the (representation) of objects.
• Run-time reflection from (object) to (properties of object).

Practice and experience have taught,
as also necessary, the inclusion of

• Closures ( sometimes referred to as "true closures",
    meaning (closures) in the formal sense,
    and following the example of closures in (lisp).
  )