I'm not sure I understand. I'm saying specifically that at the very least, this one feature of classical inheritance is not easy to implement and in fact almost always leads to bugs when people try to do it. The truth is that most of the interesting features of classical inheritance are pretty hard to implement:

1. super, as described above

2. private, protected, etc. Never seen this work in js with inheritance

3. inheriting class methods as well as instance methods

If all you care about is the most superficial copying of a superclass' methods, then yeah of course its easy to do in JS, its essentially just prototypal inheritance again. Its arguably just as easy to implement this watered down form of classical inheritance in C as well (or in any language I guess):

struct MySubclass { struct MySuperclass base; int newMember; }

I don't think this is necessarily an argument for elegance however.

The point is, if these are features that everyone has to implement, then at some point you have to say "maybe its not that everyone else is stupid and doesn't get it, but that its an actually worthwhile feature". In fact, they predicted this (which is why class and super are reserved words in JS despite not doing anything), and its supposedly expected to come in the next iteration of JS (as in, the one after the one currently not even implemented yet). So, in 50 years when we get that we'll finally have remedied this issue.

> 1. super, as described above

Make the super property a reference to the parent prototype in your "extends" function. ExtJS does this with the "superclass" property.

> 2. private, protected, etc. Never seen this work in js with inheritance

What? This is basic stuff.

Private:

  var fn = function() {};

Protected:

  this.fn = function() {};

Public:

  Cls.prototype.fn = function() {};

> 3. inheriting class methods as well as instance methods

See above. May I refer you to http://www.crockford.com/javascript/inheritance.html ?

1. As described this has serious issues when you reach depths greater than 1. This is why prototype has to use the hack of passing in a special super variable through the function arguments. This is also why in ExtJS, doing something that in any other language is a simple "super.method()" requires doing the following (from their own subclassing examples):

    Ext.ux.IconCombo = function(config) {
 
        // call parent constructor
        Ext.ux.IconCombo.superclass.constructor.call(this, config);
 
    };

Wow. Fantastic. Even if we ignore the Ext.ux, you can't tell me this isn't absolutely ridiculous. For starters, it requires access to the actual class object which is only slightly better than inlining the superclass' actual name yourself. It means if you ever change the class name there are additional points of failure (change it to IconComboBox, and now all your IconCombo.superclasses don't work if you happen to forget to modify them). Additionally, this is SO CONFUSING to beginners. Look, I can see that its "powerful" if thats what you want to call it, but people who want to write apps, and not sit around pontificating about languages have to understand so much to know what is happening in that one line of code. Beyond the verbosity, they need to get that they are taking someone else's function and then applying it to yourself while switching out the "this" (remember how I said this came into play with super calls). This is taking a problem that was hard to solve at the framework level and pushing it to the user.

2. For starters, you conveniently didn't mention how to handle private and protected member variables which is the actual interesting bit here. The goal is to not have people accidentally write into your internal data representations. This is modularization 101 and is really difficult to do with JS, since this._x = blah is accessible to EVERYONE. this._x is NOT protected in any way, every party has access to it and can change it. The "var fn" of course doesn't work with private member variables since you need one for each individual instance, you can of course do the closure trick inside your constructor:

function MyClass() { function() { var myVar = 5; this.getMyVar = function() { return myVar; } }

But this is recommended against by everyone since it 1. no longer has the benefit of modifying the prototype so its hard to inherit these methods without further trickery, and 2 is very very slow.

So no, this is not basic stuff. Not if you actually want to implement classical inheritance instead of just using names from classical inheritance and applying them to random orthogonal features.

3. Again, you run into the same super problems.

Look, I am willing to believe that people like prototypal inheritance, and I can respect the position that JS doesn't have classical inheritance because its not good or because you should use prototypal or whatever. But come on, lets not call a few hacks on top of it "classical inheritance".

Yes, I've seen Crockford's page. Its not particularly enlightening to this discussion. It presents several different forms of inherity-stuff, none of which are particularly classical in my opinion, which comes right back to the OP's original point: everyone ends up doing inheritance slightly differently and spends way too much time thinking about this problem. The fact that so much has been written on how to do inheritance in JS should be a red flag in and of itself. I will gladly take other language's "stricter less powerful" models because at least I can focus on programming and not the volumes and volumes that have been written on how to do something that should be as simple as inheriting methods.

> The "var fn" of course doesn't work with private member variables since you need one for each individual instance,

This makes me believe that you have no idea what you're talking about.

Normally I'd take the time to explain, but I'm pretty sure the code example right below that statement makes evident what I was getting at, and its pretty clear to me that you just aren't reading my responses, so there's really no point.

But you're probably right, I probably have no idea what I'm talking about despite having written a popular JS framework and the most widely used mobile browser on the planet.

That is just a ridiculous thing to say to Francisco Tomalsky - I think he's already demonstrated that he knows a thing or two about hacking JavaScript (see Cappuccino - http://cappuccino.org/learn/). How about you respond by giving us a code example that shows how he is wrong, rather than trolling?