I gather you haven't been sniffing around the ECMA specifications lately? Because there are interesting documents at <http://www.mozilla.org/js/language/
They are implementing a classical inheritance system. They are also adding typed variables, and a few new native types (Never, Void (what was formerly Undefined), Integer, Type, char; and the machine types sbyte, byte, short, ushort, int, uint, long, ulong, float). It's still backward compatible (though ECMAScript 3 was not forward compatible, so a JS1.5 parser will choke on some rather simple JS2.0)
Some reserved words are no longer reserved. Some new are added. None of the type names are reserved words, for instance, but they are constants in the global scope.
They are in other words making ECMAScript 4 more machine close, and closer to C++, further from functional languages. However, behind the scenes, things that are clearly a movement to the functional style are taking place. Primitives are no longer distinguished from compound data types - you can now create members of primitives, which you couldn't in ECMAScript 3. This means a movement towards object orientation, but also a movement towards the functional system of placing more weight in expressions and values, instead of variables and types, an effect standing in contrast to the imperative style. Closures play the same role as they did in ECMAScript 3, but they have taken a less important place as classes have come to take the place constructor functions took before - not that constructor functions are banished, they are just made redundant by the addition of classes to which you may assign custom constructors. They have sadly chosen to build a classical system for inheritance instead of extending the prototyped system of ECMAScript 3, which I would have preferred. Anyway, this means some things - you can now have virtual and final variables, which you couldn't in ECMAScript 3. It also means that classes have a broken (from an ECMAScript 3 POV) delegation system. They inherit at creation moment, and the member lookup is not exactly the same, since in ECMAScript 3 you were guaranteed that there were only a single member with a given name, which you are not in the namespaced and more complicated ECMAScript 4 system.
Well, let's have a look at object orientation for a while.
Inheritance: ECMAScript 3 is pretty clear on this. Inheritance
can be done both by aggregation and by dynamic lookup. Closures and a bit of trickery allows us to create public, private and even protected members. And we can create privileged members as well (public members with access to private members). For more information on this, I would recommend not only Douglas Crockford
which you all should know by now, but also the a bit more technically correct Jeff Yates
. There. That also covers Encapsulation
, as that is just what private, public and protected members mean. How about Polymorphism
, then? Well, ECMAScript performs implicit type coercion when required, and you may force it usinbg explicit coercion as well. We may not create operators and that means that operator overloading outside what is built in to the native types is prevented, and we may not declare more than one function with the same name. However, we aren't entirely left behind here. We have a dynamic, weakly typed language. That means that though we can't force the type of arguments sent to a function, we may detect them and act thereupon inside the function - the process of code forking. Abstraction
- well, you said it. Everything is an object. It has most criteria for object orientation - and those it doesn't have are those that essentially divides weakly typed languages from strongly typed languages, and dynamic langauges from static - criterions that are very biased towards compiled, imperative languages, because that's their way of data handling.