Why to set prototype.constructor at all?

[wilq]

I'm struggling with this problem for some time, and looking for clear
answer... Why this is commonly adviced to set
myObject.prototype.constructor back to myObject in any prototypical
coding in JS? I heard some version with constructor being wiped out
(sic!) or instanceof not working correctly, but all mine test shows
that its completly fine. Is this usefull in any inheritance pattern? I
just find out that this could be helpful if you test inside function
things like:

this.constructor == myObject

but usually you would do

this instanceof myObject

that would work even without setting .prototype.constructor back to
myObject...

So... can anyone help me please? Some examples or links to post would
be really great! I already look on this group, but I never saw a topic
strictly about this subject so I hope you don't get bad if this was
already discussed before...

Here is a code that based on I did some test:

var Parent = function(){
alert("parent constructor");
}

Parent.prototype.parentFunc = function(){
alert("I'm a parrent");
}

var Child = function(){
alert("child constructor");
}

Child.prototype = {
childFunc : function(){
alert("I'm a Child");
}
}
//Child.prototype.constructor = Child;

var a = new Child();
alert(a instanceof Child);
alert(a instanceof Parent);

 

[Richard Cornford]

I'm struggling with this problem for some time, and looking
for clear answer... Why this is commonly adviced to set
myObject.prototype.constructor back to myObject in any
prototypical coding in JS?

First, it is important to remember that the vast majority of the
people working with javascript have little real understanding of what
they are doing, and that many subside understanding with sequences of
blanket injunctions and mystical incantations, which they then tend to
promote to others (perhaps in an effort to justify their own actions.
Generally, if someone advises, advocates, promotes, etc. something you
need to pay close attention to the reasoning that they provide to
justify it, and when no reasoning is provided, or that reasoning is
unconvincing or false then regard the advice as dubious. (asking
questions at this point, as you are here, is a good idea, assuming the
person you are asking is willing to participate in the exchange).

I heard some version with constructor being wiped out
(sic!)

When a function is created its - prototype - property is assigned a
reference to an object, and that object is given a - constructor -
property that refers to the function. Any action that results in the -
prototype - property of the function referring to another object will
effectively remove the reference to the function from the prototype
chain of object subsequently constructed with the function. Unless
some remedial action is taken.

or instanceof not working correctly,

The - instanceof - operator has absolutely no interest in -
constructor - properties or their values. This folk-law assertion
about - constructor - properties is false.

but all mine test shows that its completly fine.

Which is fine? Using - instanceof - should not be effected by actions
relating to - constructor - properties.

Is this usefull in any inheritance pattern?

Only if you do direct comparisons between an object's - constructor -
property and a function. That can be used for 'type' identification,
but is not necessary for 'type' identification, and when it is not
being used there is no good reason for messing around with -
constructor - properties.

I just find out that this could be helpful if you test
inside function things like:

this.constructor == myObject

but usually you would do

this instanceof myObject

"Usually" would be a bit subjective. Personally I don't use the -
instanceof - operator, so that would be very unusual.

that would work even without setting .prototype.constructor
back to myObject...

Yes it would.

So... can anyone help me please?

In what sense? Are you looking for a justification for always setting
the - constructor - property? The only justification for that boils
down to 'just in case you (or someone else) may want it later'.

Some examples or links to post would
be really great!

Examples of what exactly?

I already look on this group, but I never saw a topic
strictly about this subject so I hope you don't get bad
Mad?

if this was already discussed before...

<snip>

It has been discussed before, but hopefully I have given the
impression that it is not a subject with an absolute answer (and so
probably should not be the subject of a blanket injunction, either
way). There is nothing wrong with going over subjects again, as
thought may change and new people may raise new (and possibly
interesting/pertinent) points.

Richard.

 

[Hubert Kauker]

I heard some version with constructor being wiped out
(sic!) or instanceof not working correctly, but all mine test shows
that its completly fine. Is this usefull in any inheritance pattern?
...
but usually you would do
this instanceof myObject
that would work even without setting .prototype.constructor back to
myObject...

As Richard pointed out the instanceof operator has nothing to do
with what value you assign to the constructor property.
Consider the following examples:

function MyClass() {
// ...
}

function OtherClass() {
// ...
}

var myObj = new MyClass();
alert( myObj instanceof MyClass ); // true

MyClass.prototype.constructor = OtherClass;
alert( myObj instanceof MyClass ); // true

myObj.constructor = OtherClass;
alert( myObj instanceof MyClass ); // true

Only when trying to be 'clever', for example implementing
some Java-like 'inheritance' like this:

// MyClass extends OtherClass
MyClass.prototype = new OtherClass();
var myObj = new MyClass();
alert( myObj instanceof MyClass ); // true
alert( myObj.constructor === MyClass ); // false: confusing.

In such a setting you would probably feel the need to set:
MyClass.prototype.constructor = MyClass;

This would then allow you to create instances using
var myObj2 = new myObj.constructor();
which looks a little like Java's 'reflexion'.

Hubert.

 

[Thomas 'PointedEars' Lahn]

Consider the following examples:

function MyClass() {
// ...
}

function OtherClass() {
// ...
}

var myObj = new MyClass();
alert( myObj instanceof MyClass ); // true

MyClass.prototype.constructor = OtherClass;
alert( myObj instanceof MyClass ); // true

myObj.constructor = OtherClass;
alert( myObj instanceof MyClass ); // true

JFTR: There are no classes.

Only when trying to be 'clever', for example implementing
some Java-like 'inheritance' like this:

// MyClass extends OtherClass
MyClass.prototype = new OtherClass();

That is _not_ "implementing some Java-like 'inheritance'"; almost all
examples on the Web regarding this derive from or copy the oversimplified
example in the original Netscape JavaScript Guide, and are misleading.
MyClass instances would only inherit from a single OtherClass instance
instead of from OtherClass's prototype directly then.

The proper way to do this, discussed often before, goes like this:

function Dummy() {}
Dummy.prototype = OtherClass.prototype;
MyClass.prototype = new Dummy();

See also Function.prototype.extend() in

var myObj = new MyClass();
alert( myObj instanceof MyClass ); // true
alert( myObj.constructor === MyClass ); // false: confusing.

In such a setting you would probably feel the need to set:
MyClass.prototype.constructor = MyClass;

Indeed. It should be noted, though, that this property, being user-defined,
would be enumerable by default. It can be avoided in for-in iteration in
ECMAScript-3-conforming implementations by providing and using an iterator
that ignores it, and in ECMAScript-5-conforming implementatons by defining
the property as not enumerable. The former is already present in
JSX:Function.prototype.extend(); I have just finished the latter locally
which will enter the online codebase with one of the next revisions.

This would then allow you to create instances using
var myObj2 = new myObj.constructor();

That is one application of it.

which looks a little like Java's 'reflexion'.

You mean Reflection, which is also available in other programming languages:

<http://en.wikipedia.org/wiki/Reflection_(computer_science)>


PointedEars

 

[wilq]

I warmly thank you all for detailed response that just confirm some of
my predictions here,

Thanks again,
Wilq32