liorean liorean at gmail.com
Sat Sep 22 14:52:40 PDT 2007

On 22/09/2007, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> What I've found is that it's always giving wrong constructor property
> with inheritance chains.
> A <-- B <-- C
> c = (new C).constructor;// A
> So to do this, I can use a chaining technique to hardcode the
> inheritance structure reading __proto__ or using hand-rolled
> constructor chaining, but then that requires that clients who try to
> get the constructor build their inheritance with the same approach
> that I do, and get an enumerable constructor property on their class
> as a side effect.

You get that if you do the following:

    function A(){}
    function B(){}
    B.prototype=new A;
    function C(){}
    C.prototype=new B;

Because if you do that, you replace the prototype containing the
original constructor property  (e.g. a reference back to the function
C) with an instance of another constructor (e.g. B), but that instance
doesn't have the constructor property that the original prototype had.
If you want to keep the constructor properties, you need to do that
manually. (With the obvious result that then the constructor property
will be enumerable. Which can be changed through adding a call on
propertyIsEnumerable in ES4.)

> The chaining technique was published many years ago by Kevin Lindsey
> and used by some popular libraries like YUI.

It's actually far older than that, and I think the Netscape JavaScript
guides and references even contained a crash course in this. I think
it's mentioned in my oldest JavaScript books, published around 1996.

> How about a constructor property on the function instance?

Wouldn't help, the constructor property would have to be set on the
object the constructor builds.

Which could be done, of course, it should be a simple thing to add
that in the algorithm for [[Construct]]. But then we have the question
of what to do with constructors that return other objects than that
set up by steps 1 through 5 of the [[Construct]] algorithm. A
constructor can return other objects, you know. You'd have to decide
whether this property should be set up prior to step 6 in the
algorithm or subsequent to step 7. If prior, only the original object
that was created in step 1 gets it, if subsequent, return values get
it even if they are not the same as the original object.

Actually, I think this would be a nice and simple fix to ES3 that
probably wouldn't hurt much code out there.
David "liorean" Andersson

More information about the Es4-discuss mailing list