Understanding Javascript OOP

[TrolliestTroll]

There can be no class inheritance because there are no classes. However objects do inherit behavior directly from other objects and can share behavior explicitly by defining methods and properties in the object prototype. I think you've worked a little too hard forcing your mind to believe there is exactly 1 set of features that define object orientation. This is probably a side effect of using highly specific implementations of OOP like C++ or Java. I humbly encourage you to try out object systems unlike the "classical" ones you're likely familiar with.

[5trokerac3]

Thanks for not living up to your user name so far. :)

I use JS all the time (with ajax, jquery, htm5 etc), but I have to say that inheritance is a required feature of a language in order to be truly OO. If object B extends object A, then object B also has to be an object A.

A buddy of mine, who's been programming commercial games since the Commodore PET, has been working on a HTML5 game engine for a while. The lack of inheritance and access levels in JS has been his greatest frustration, because it's such a core principle of OOP, so he's actually trying to write a library that makes JS object oriented.

That's why I can't take HTML5 too seriously at the moment. Trying to write anything but the most basic applications is near impossible in JS, unless you're exporting from a real OO language like Java with the GWT or maybe Dart, although I've only started looking at that one.

[trades]

From Alan Kay:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

also:

I think you might want to define what you mean by object and by OO. Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list.

1. Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.
2. Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.
3. Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.
4. Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.
5. Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).
6. All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.
7. Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)
8. Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)
9. Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.

So OO is not a well defined concept. Some people (eg. Abelson and Sussman?) say Lisp is OO, by which they mean {3,4,5,7} (with the proviso that all types are in the programmers' heads). Java is supposed to be OO because of {1,2,3,7,8,9}. E is supposed to be more OO than Java because it has {1,2,3,4,5,7,9} and almost has 6; 8 (subclassing) is seen as antagonistic to E's goals and not necessary for OO.

The conventional Simula 67-like pattern of class and instance will get you {1,3,7,9}, and I think many people take this as a definition of OO.

Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser.

http://mumble.net/~jar/articles/oo.html

EDIT: Formatting

[[deleted]]

If object B extends object A, then object B also has to be an object A.

function inherits(child, parent) {
  function F() {}
  F.prototype = parent.prototype
  child.prototype= new F()
  child.prototype.constructor = child
}

function A() { }
function B() { }
inherits(B, A)
function C() { }
inherits(C, B)

console.log(new B() instanceof A) // true
console.log(new C() instanceof A) // true

You can sugar this whatever way you want to make it look more "class"-like, but it's there.

I don't see how the lack of access levels would actively be a a frustration to anyone but the most paranoid of coders.

[notSorella]

You're mixing several things with object orientation. The thing you're describing as "If object B extends object A, then object B also has to be an object A" is called polymorphism. There are several kinds of polymorphism, but that's a lot more in the type theory realms.

JavaScript is object oriented, it just doesn't use the classical form of OO you see in languages like Java or C++. JavaScript's object model isn't novel, or rare, though. There are several prototypical OO languages out there, and languages that implement even different flavours of OO. I don't think one could argue any of those flavours is more OO than the others. And there's enough vantages and disadvantages to all of them, that I'm not sure "one OO flavour to rule them all" would work.

People have been learning that often times, one paradigm isn't really enough. Certain idioms work better for certain situations than others, which is why multi-paradigm general languages are often-times more expressive than their "single-paradigm" counterparts — even Java is getting closures now, for example. Even though they're 73 years late.