Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > constructor for a derived object is same as that of its parent

Reply
Thread Tools

constructor for a derived object is same as that of its parent

 
 
satyajit
Guest
Posts: n/a
 
      11-29-2006
I am trying to learn the concept of constructors in ECMAScript. I
executed following code (See execution in Rhino JavaScript shell):
function Foo(a)
{
this.a = a;
}

function Bar(b)
{
this.b = b;
}
Bar.prototype = new Foo(1);
var x = new Foo(2);
var y = new Bar(3);

Now I expect y.constructor to give me Bar, but I am getting Foo.
Can anybody explain?

Following the execution sequence in Rhino JavaScript shell:

Rhino 1.6 release 5 2006 11 18
js> function Foo(a)
{
this.a = a;
}
js> function Bar(b)
{
this.b = b;
}
js> Bar.prototype = new Foo(1);
[object Object]
js> var x = new Foo(2);
js> var y = new Bar(3);
js> x.constructor

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

js> y.constructor

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

Regards,
Satyajit

 
Reply With Quote
 
 
 
 
VK
Guest
Posts: n/a
 
      11-29-2006

satyajit wrote:
> function Foo(a)
> {
> this.a = a;
> }
>
> function Bar(b)
> {
> this.b = b;
> }
> Bar.prototype = new Foo(1);
> var x = new Foo(2);
> var y = new Bar(3);
>
> Now I expect y.constructor to give me Bar, but I am getting Foo.


Yep... And at the same
alert(y instanceof Bar); // true
or (the same but more "conceptual"):
alert(Bar.prototype.isPrototypeOf(y)); // true

Tricky, is not it?

I highly suggest you to read and study all samples from:

Eric Lippert
"The JScript Type System, Part Two: Prototypes and constructors"
<http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx>

This rather short blog post is the *only one* source about JavaScript
inheritance currently existing in the Internet. There can be more of
course, but my two years search did not reveal them. Anything else I
could find is either an erroneus crap or multi-paged revelations
leaving you even more confusing then ever before.

P.S. Eric Lippert is the original maker of Microsoft JScript engine.
That doesn't mean that you have to take each his word as the final
truth: there is a difference between a piano maker and a piano player
I just thought that it should be mentioned that he is not some
"side ECMAScript specialist".

 
Reply With Quote
 
 
 
 
Martin Honnen
Guest
Posts: n/a
 
      11-29-2006
satyajit wrote:
> I am trying to learn the concept of constructors in ECMAScript. I
> executed following code (See execution in Rhino JavaScript shell):
> function Foo(a)
> {
> this.a = a;
> }
>
> function Bar(b)
> {
> this.b = b;
> }
> Bar.prototype = new Foo(1);
> var x = new Foo(2);
> var y = new Bar(3);
>
> Now I expect y.constructor to give me Bar, but I am getting Foo.
> Can anybody explain?


This has confused a lot of people but it only shows that the constructor
property is not very intuitive respectively not set in a way that
follows the intuition people have that think in class based terms and
expect "instances" in JavaScript to have a property named constructor
that points to the function constructor.

You might want to check
y.hasOwnProperty('constructor')
and you will find that y does not have an own property of that name.
That means when y.constructor is looked up that the prototype chain is
used to look for the property and so the lookup first looks at
Bar.prototype having a constructor property but it does not have one meaning
Bar.prototype.hasOwnProperty('constructor')
is false too, then follows the lookup of Foo.prototype and
Foo.prototype.hasOwnProperty('constructor')
is true and that constructor property has been set when the Foo function
was created according to section 13.2 of the ECMAScript edition 3
specification.

--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      11-29-2006
satyajit wrote:
> I am trying to learn the concept of constructors in ECMAScript. I
> executed following code (See execution in Rhino JavaScript shell):
> function Foo(a)
> {
> this.a = a;
> }
>
> function Bar(b)
> {
> this.b = b;
> }
> Bar.prototype = new Foo(1);
> var x = new Foo(2);
> var y = new Bar(3);
>
> Now I expect y.constructor to give me Bar, but I am getting Foo.
> Can anybody explain?

<snip>

When a function object is created it is given a - prototype - property
and that property is assigned a value that is a reference to an object.
That object is then given a - constructor - property that is assigned a
reference to the function object.

If the function object is used to construct an object the value
currently assigned to its - prototype - property is assigned to the new
object's internal [[Prototype]] property, which is then used as the
first object in the new object's prototype chain. Thus this new object
inherits a reference to the function object used as its constructor
through its prototype chain.

You have replaced the object originally assigned to - Bar.prototype -
with an instance of Foo. Thus the object that had the - constructor -
property that referred to Bar has been replaced with an object that is
inheriting a constructor - property through its prototype chain from -
Foo.prototype -. And when that object is assigned to the internal
[[Prootype]] properties of objects created with - new Bar - they
inherit its - constructor - property.

You can mitigate that issue by doing:-

Bar.prototype = new Foo(1)
Bar.prototype.constructor = Foo;

- and then new instances of Bar will inherit a - constructor - property
that refers to - Foo -.

However, you really should not be writing javascript code in which you
need to test for the constructor of any objects (outside of
experimental and testing code). There are no casting issues in
javascript as all objects are really of a single 'class' and in a
loosely typed language like javascript it is a necessary discipline for
the programmer to be keeping track of the types being used and so
situations where you need to query a type at runtime are exceptional.

Richard.

 
Reply With Quote
 
Martin Honnen
Guest
Posts: n/a
 
      11-29-2006
Richard Cornford wrote:

> You can mitigate that issue by doing:-
>
> Bar.prototype = new Foo(1)
> Bar.prototype.constructor = Foo;
>
> - and then new instances of Bar will inherit a - constructor - property
> that refers to - Foo -.


How does that mitigate things? The original poster complained about Foo
being returned by y.constructor and wanted Bar instead. That code above
does not change that, unless you wanted to set
Bar.prototype.constructor = Bar;



--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      11-29-2006
Martin Honnen wrote:
> Richard Cornford wrote:
>
> > You can mitigate that issue by doing:-
> >
> > Bar.prototype = new Foo(1)
> > Bar.prototype.constructor = Foo;
> >
> > - and then new instances of Bar will inherit a - constructor - property
> > that refers to - Foo -.

>
> How does that mitigate things? The original poster complained about Foo
> being returned by y.constructor and wanted Bar instead. That code above
> does not change that, unless you wanted to set
> Bar.prototype.constructor = Bar;


You are right. I intended to type Bar and typed Foo instead.

Richard.

 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      11-29-2006

satyajit wrote:
> I am trying to learn the concept of constructors in ECMAScript.


You may enjoy this tutorial

http://kevlindev.com/tutorials/javas...ance/index.htm

And at least the first of these three videos

http://yuiblog.com/blog/2006/11/27/v...ockford-advjs/

Peter

 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      11-29-2006
Peter Michaux wrote:
> You may enjoy this tutorial
>
> http://kevlindev.com/tutorials/javas...ance/index.htm
>
> And at least the first of these three videos
>
> http://yuiblog.com/blog/2006/11/27/v...ockford-advjs/


Video is good (though the downstream from the Yahoo server seems poor
as it chocks even on my DSL).

The inheritance article (the first one) is a rather dangerous reading.
It is one of countless "C++ over JavaScript" tutorials: a little
preface about prototype inheritance (just few words do not make a
C++'er too much bored) and then quickly move onto the main part: how to
build inheritance in the "conventional proper" way and do not be
bothered with that stupid prototypes anymore. Such articles constitute
90% of "inheritance in JavaScript" sources, but this one admittedly is
of much better quality than many of what I've seen.

I mean hell - I use "classy" emulation in JavaScript left and right
myself because it's often more easy and quickly in a mixed environment.
But if anyone is targeted to understand how is it *really* ticking
(even if never come to it again and just stick to say prototype.js)
then such articles should be read only after the one I posted.

 
Reply With Quote
 
John G Harris
Guest
Posts: n/a
 
      11-29-2006
In article <(E-Mail Removed). com>,
Richard Cornford <(E-Mail Removed)> writes

<snip>
>However, you really should not be writing javascript code in which you
>need to test for the constructor of any objects (outside of
>experimental and testing code). There are no casting issues in
>javascript as all objects are really of a single 'class' and in a
>loosely typed language like javascript it is a necessary discipline for
>the programmer to be keeping track of the types being used and so
>situations where you need to query a type at runtime are exceptional.


To add to that, the 'constructor' property is like 'with' and two-digit
year numbers : each seemed a good idea at the time, but in practice each
causes a lot of confusion and can be done better a different way.

John
--
John Harris
 
Reply With Quote
 
satyajit
Guest
Posts: n/a
 
      11-30-2006

Martin Honnen wrote:
> Richard Cornford wrote:
> > You can mitigate that issue by doing:-
> >
> > Bar.prototype = new Foo(1)
> > Bar.prototype.constructor = Foo;
> >
> > - and then new instances of Bar will inherit a - constructor - property
> > that refers to - Foo -.

>
> How does that mitigate things? The original poster complained about Foo
> being returned by y.constructor and wanted Bar instead. That code above
> does not change that, unless you wanted to set
> Bar.prototype.constructor = Bar;


Thanks VK, Martin, and Richard for very explanations. Got the reason
after I read Eric Lippert blog.

I did not want to set "Bar.prototype.constructor = Bar;" but was trying
to find out how the constructor and prototypes work. The version of
ECMAScript standard that I got originally from ECMA's site was ECMA-262
standard and that did not have reference to instanceof and
isPrototypeOf(). Getting these concepts from the standard was very
difficult.

However one thing I noticed in the ECMA standard that the String
behaves differently when called as constructor and as function. I
wanted to explore how to do that for my own functions that can be used
as constructor or as conversion type. I tried to make sense of some
earlier posts but could not do so.

- Satyajit

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Derived::Derived(const Base&) and Derived& operator=(const Base&) developereo@hotmail.com C++ 1 05-23-2007 01:44 PM
Derived::Derived(const Base&) and Derived& operator=(const Base&) developereo@hotmail.com C++ 1 05-23-2007 12:07 AM
Need to pass a value from an IFrame to its parent to its parent PKalos@gmail.com Javascript 0 02-02-2006 10:02 AM
Derived class & objects to parent constructor Doug Java 7 05-13-2004 12:43 PM



Advertisments