Yes, absolutely correct, there is such a check first. Though this should go without saying, because the name of the instanceof operator already assumes that it works with an instance on the left hand side and with the constructor function on the right hand side.

Notice also, that in first your example c1.prototype = c2; does nothing special but just creates a casual property prototype on the object, it doesn’t setup inheritance in this case, since again c1 is not a constructor. If you want to play with inheritance of simple object, try using c1.__proto__ = c2; (works not in all browsers), or from ES5 — var c1 = Object.create(c2);.

I have tried a demo as below:

function B() {}
var b = new B();
alert(b instanceof B); // true

var c1 = {};
var c2 = {};
var c3 = {};
c1.prototype = c2;
c2.prototype = c3;
c3.prototype = B.prototype;
alert(b instanceof c3); // true

But it says that “Uncaught TypeError: Expecting a function in instanceof check, but got #<B>” under Chrome.
After I changed the code as below:

function B() {}
var b = new B();
alert(b instanceof B); // true

var c1 = {};
var c2 = {};
var c3 = function() {};
c1.prototype = c2;
c2.prototype = c3;
c3.prototype = B.prototype;
alert(b instanceof c3); // true

So, I think maybe the function check is first applied for the instanceof operator, after that, just as you have mentioned in this article.

Since you can get ‘x’ via A.prototype anyway, why is it so important to make it native?

It’s only to imitate the approach with classes — there state variables are native, not inherited. If you use a prototypical approach you may not create own x, but reuse it from the parent prototype.

Notice though, that there is a subtle case with object properties here. E.g.:

// constructor

function Foo(name) {
  this.name = name;
}

// prototype (shared) properties

Foo.prototype.data = [1, 2, 3];

Foo.prototype.showData = function () {
  console.log(this.name, this.data);
};

// instances

var foo1 = new Foo("foo1");
var foo2 = new Foo("foo2");

// both instances use
// the same default value of data

foo1.showData(); // "foo1", [1, 2, 3]
foo2.showData(); // "foo2", [1, 2, 3]

// however, if we change the
// data from one instance

foo1.data.push(4);

// it mirrors on the second instance 

foo1.showData(); // "foo1", [1, 2, 3, 4]
foo2.showData(); // "foo2", [1, 2, 3, 4]

So in case when we need own properties (i.e. per instance), we create them in the constructor, not on the prototype. The prototype though can store some default values, but the case above should be considered.

In java(static classical language), inheritance is intuitive, you can understand the relationships among classes, instances at first glance. But with javascript, all the prototype properties, __proto__, constructor properties, it’s very complicated.

That’s why you may create such a wrapper and program in classical approach not bothering with prototypal nature. But actually, there is no big difference in classical approach and prototypal — in both cases the inheritance chain is considered: in the class-based system it’s a chain of classes, in the prototype-based — it’s a prototype-chain.

Take a look only on CoffeeScript’s classes: http://jashkenas.github.com/coffee-script/#classes You may see how Coffee compiles its code into JS and to understand how JS works.

Are there any best practices in JavaScript inheritance? Please suggest some reading materials.

It depends on the situation. In one case it can be convenient to program in classical approach. In other one — to use the prototypal one. You may read also chapter 1 of the ES5 series where the OOP API of ES5 (with controlling property attributes, with inheriting without constructors via Object.create, etc) is described.

Dmitry.

In java(static classical language), inheritance is intuitive, you can understand the relationships among classes, instances at first glance. But with javascript, all the prototype properties, __proto__, constructor properties, it’s very complicated. (Oh, thank you for your figure 3 in JavaScript: the core article. It helps a lot understanding prototype chain. )

Are there any best practices in JavaScript inheritance? Please suggest some reading materials.

Oh, it was my previous thoughts about strict mode (and this comment above was written before I wrote a detail analysis on strict mode and dug it deeply).

Now my meaning is changed since strict mode in ES5 (and in Perl I guess, though I’m not a Perl programmer) is a transitional version of the language. The next version, ES6 will be based exactly on ES5-strict.

The thing I mentioned (which probably I don’t like) is exactly splitting the language on strict and non-strict. I.e. constant presence of these two modes. If to accept that this mode is only transitional (and in ES6 we won’t have to choose the mode) it’s completely OK — just a graceful transition from old version (with deprecated stuff) to the new one.

A detailed info on strict mode exactly in ES can be found in the appropriate ECMA-262-5 in detail. Chapter 2. Strict Mode..

Dmitry.

(as it is in Perl — ask any professional Perl programmer whether he uses strict mode – he’ll answer: “Yes of course”, but ask then “why?” — there will be no unequivocal answer), providing useless overloading in code. And of course the most funny answer is “Programming in strict mode is more professional”.

No, the only answer is, that you avoid typos – that’s the only, but good reason.

But I think there are some difference between use strict in Perl and JS. But I won’t argue for strict in JS, because I don’t know enough about it.

Would have saved me two weeks of recherches, if I’d found it earlier

Someone should have told people about JavaScript OO internals ten years ago, I salute you for making this effort!

when the program run to the anonymous function on firefox, the istype function is called.

It’s the subtle case of ASI (Automatic semicolon insertion) mechanism. The surrounding parentheses of your second immediately invoked function, actually the call parentheses of the first function.

I.e. the first anonymous function is created and also immediately executed (at this moment it isn’t even assigned yet to istype variable). You may rewrite this code in this way:

// pass the second function as
// argument for the first one
(function(obj) {...}(function(){alert("i am running!")}));

Thus, as you see, the second function is passed as an argument for the first one.

Accordingly, if you call the second function before passing as argument, then the result of the second function is passed as the argument for the first one function:

// pass the result of the second function -
// see call parentheses - (), the result is
// undefined, and this will be the value of
// "obj" argument
(function(obj) {...}(function(){alert("i am running!")()}));

And only after that the result of the first function is assigned to the istype variable (which is also undefined — i.e. the implicit returned value of the first function).

To fix your situation, just put explicit semicolon after the first function. Thus, the parser understands where the first part ends and starts the second one:

var istype = function(obj)
{
    debugger;
};
(function(){
    alert("i am running!")
})();

P.S.: Take a look also on Chapter 5. Functions.

Dmitry.

(function(){
    alert("i am running!")
})();