Just as well, because the function Crockford published on his site (http://www.crockford.com/javascript/inheritance.html) doesn’t work in the general case. Try it for more than three levels of inheritance. Caused me such a headache :(

P.S. sorry I realise this is a very old thread!

The first and most important thing to say is that I am glad that you see the value of a consistent development model. That being said, I leave you with some Crockford, in particular the last bit, and the thought that it is to me ridiculous to say that the most popular language in the world has a model that is hard to use:

JavaScript can be used like a classical language, but it also has a level of expressiveness which is quite unique. We have looked at Classical Inheritance, Swiss Inheritance, Parasitic Inheritance, Class Augmentation, and Object Augmentation. This large set of code reuse patterns comes from a language which is considered smaller and simpler than Java.

Classical objects are hard. The only way to add a new member to a hard object is to create a new class. In JavaScript, objects are soft. A new member can be added to a soft object by simple assignment.

Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.

I coded things in regular old script before using a lib (not for long, it sucks) and even used Mootools without digging into the Class framework for quite a while. The thing is when I started using classes the pieces fit together so seamlessly. Binds, mutators, chaining, binding with custom events, extensibility of the code, DRY, reuse++, modularity, class inheritance and extends, it makes it a snap to do just about anything cleanly and efficiently with little fuss.

I would never go back, ever. Just a different world when you dig into it.

Oh yeah Mootools! that’s right!

Here is my analogy for this article:

When IE first did tabbed browsing lay people everywhere were like “Oh my god tabs how awesome.” I can vouch, I still have friends who aren’t working in internet technology who think FireFox is the one doing the UI and functional copying…

So I see this post, and so many recently, in much the same way, namely: “Oh my god look what you can do with jQuery, brilliant!!!” – make sure to read emphatically like a guinness commercial puppet for full effect.

Using Google more would solve many problems folks, there is the whole new world out there beyond the little js lib box. (don’t bust my balls over the chance Aladdin reference). I mean I don’t use jQuery much but I read John’s blog sometimes and try and stay up with developments they do…

forgot to use the tag [sarcasm][/sarcasm]


...
if(this.constructor == Object || typeof this.init != undefined) {
...

The latter expression will always evaluate to `true`, since `typeof` always returns a string. Did they forget quotes around `undefined`. It’s also not clear why there is a limitation of `constructor` being an Object. What if I want to pass an object that inherits from `Object.prototype` but doesn’t really have `Object` as its `constructor`? It would be better to check for either [[Class]] or use `typeof`.

Another oddity:

$.each(ns, function() {
_this.namespace.apply(_this, [this]);
});

Nice. Creation of a useless array in a loop just to pass it to `apply`? `call` would do just fine (and faster and more memory effecient, of course)

Further down, we have:

...
for(i in this) {
...

which obviously creates `i` in a global scope : /

And another case of inefficient array creation in a loop:

...
if(extendee[i] && extendee[i].constructor == Function && ['namespace','create','sup'].indexOf(i) == -1) {
...


I also don’t see how it’s modeled after Prototype.js. Prototype.js uses `beget`-like pattern for inheritance. They, on the other hand, seem to manually iterate over methods with for/in. Those are 2 completely different approaches.

There’s also no fix for JScript’s DontEnum bug, which might bite them one day. I also couldn’t find any unit tests…

From the source of his post:
// Happy April Fools Day 2008
// The code is good – read for inspiration, but
// please don’t use this :-(

I never really understood the point in trying to make JavaScript something it’s clearly not. Prototypal inheritance CANNOT go hand in hand with classical – consigning to one is the only way in my opinion.