'this' takes all of about 5 minutes to understand in Javascript. It's pretty logical and there aren't really any surprises. Same with the prototypal inheritance.

=== "Provides convenience functions for working with prototype chains." That has nothing to do with what makes the this keyword special in JavaScript, beyond prototypes affecting this' properties.

Yes, that's pretty much what an object system is, isn't it? It's some convenience behaviour, but it would be nice if the language had a built-in way of doing things that wasn't so inconvenient.

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.

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() {};

  this.fn = function() {};

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

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

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

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.

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

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.

The baseless assertion rears its head again. People keep repeating this, and it's not true. JavaScript is not Scheme. It's not any more Scheme-like than Java, C++, Python, Perl, or many other languages. Lua and Ruby are far more Scheme-like than JavaScript.

I've commented before on people repeating this statement without ever examining it. I don't want to dredge up the arguments against it again ( http://news.ycombinator.com/item?id=1171202 ), mostly I just want to whine at it because it's so annoying. Why do you have to make JavaScript seem like something it's not? Are you trying to seem cooler by equating the language you work in to Scheme? What's wrong with JavaScript just being what it is?

In "Coders at Work", page 141, Brendan Eich talks about wanting to build a scheme-like language for the browser. The c-like syntax was adopted because Netscape wanted it to look like Java.

    Scheme: First-class functions, tail-call elimination, macros,
            hygienic macros, write and parse the AST directly.
    JavaScript: First-class functions.
    
    Scheme: Immutable arrays and lists, mutable strings.
    JavaScript: Mutable-only arrays, immutable-only strings.

If I were describing JavaScript to someone who was a programming language expert but somehow was never exposed to it, I would describe it as "Scheme, with C syntax, no tail calls, and a strange prototype-based object system".

They should; Perl 5 compares quite well and Perl 6 fares even better (of the nine fundamental features of a Lisp, lacking only homoiconicity). See the book Higher-Order Perl, for example.

http://hop.perl.plover.com/

While Scheme's syntax superficially looks like it's data, specification does not imply that there should be accessible AST as list structure anywhere (in contrast to Common Lisp, which is specified in terms of list structures and algorithm to build them from text serialization)

And by the way: You have left off the one most important defining feature of Scheme: first-class continuations. And JavaScript really does not have them (I would say that this is completely reasonable omission for JS's purpose)

It is interesting to imagine what could have happened if Netscape had shipped with a Lisp. Probably a lot more people would hate Lisp today!

So I can't really agree that it's not any more Scheme-like than anything else out there. I do agree it's not particularly Scheme-like.

[1] IIRC eg in this presentation: http://www.infoq.com/presentations/The-State-and-Future-of-J...

Err, I tested this on Chrome's Inspector console, and I don't see such behaviour. The article says name should be undefined at the time of the comparison in the below code, but it isn't (and I frankly can't see why anyone would want it to be). Is this a feature of my execution environment, or have I just completely misunderstood what the author means?

  (function(name){var cmp=name=="tim"; var name; return cmp})("tim") // returns true

    (function(name) { var cmp = function() { return name=="tim"; }; var name; return cmp();})("tim");

  a=1

  $a = 1;
  function qqq() {
    global $a;
    unset( $a );
  }
  qqq();
  var_dump( $a );

When running, I want enough flexibility to move freely but not so much that my knees break. When programming, I'd like to rely on "undefined" not being 6, and I'd even like to have a reasonable built in dictionary type that other code can't extend to add keys to by default, or overwrite "hasOwnProperty".

I.e. you just create reference to a global variable. Unsetting reference just breaks the tie between variable name and content.

There's a $.hitch plugin in JQuery, it doesn't come with it by default.