Inheritance?

[Lasse Reichstein Nielsen]

// It would be nice to get a reference to C2
// by using:
alert(obj1.constructor.constructor);
// but it returns native Function constructor

That could be due to my ignorance (and it most probably is) but "the
end of chain" comes too quickly. I would prefer to have constructors
inheritance tree but itself and do not bother with it manually.

"Constructor functions" in Javascript are not part of the inheritance
chain at all. In your example, you have no inheritance at all, except
what is created by the "new C1()" expression.

....
There are a lot of things one can do with JavaScript ;-)
But what would be the purpose of the above? And how does it facilitate
the inheritance management?

The clone function takes an object as parameter, and then creates a
new object with the given object as its prototype. That means that

var o = {};
var p = clone(o);
o.foo = 42;
alert(p.foo); //alerts 42, because "p" inherits all properties from "o".

Try this usage of "clone" for inheritance:

function LC2() {
this.foo = 42;
}
LC2.prototype.getFoo = function getFoo() { return this.foo; };

function LC1() {
LC2.call(this);
this.bar = 37;
}
LC1.prototype = clone(LC2.prototype);
LC1.prototype.constructor = LC1;
LC1.prototype.getBar = function getBar() { return this.bar; };

var l1 = new LC1();
alert(l1.getFoo());

LC2.prototype.getBaz = function getBaz() { return "voodoo"; }
alert(l1.getBaz());

Here you see actual inheritance between objects. The created object
referred to by "l1" has both LC1.prototype and LC2.prototype in its
prototype inheritance path.

The constructor functions themselves are forgotten as soon as the
objects are created. They merely initalize the object. You can
visualize it as:


LC2 -------- .prototype ------> { getFoo: ... }
^ ^
|(calls) | [Proto]
LC1 -------- .prototype ------> { getBar: ... }
^
| [Proto]
l1


The inheritance happens between the objects only. Functions are merely
mediators for creating the new objects and giving them a prototype
chain. The default chain of a new object, if you don't change the
prototype object of a constructor function, is just the function's
prototype object followed by (the initial value of) Object.prototype.


/L

 

[ron.h.hall]

If you bother to read ECMA 262, v3, sections 11.2.2 and 13.2.2 you'll
see that they're remarkably clear and exactly what I said.

Fine, I mis-interpreted what you were saying to some extent. If you
(bother to ) read what I said, I wasn't absolute about it, there was
an "I believe" qualification. Whether it's 'exactly' as you said is
highly debatable, but who has the time or interest for that? I now
understand, at least, what you were trying to say ;-).

The only thing that most people see when they look at the external
declaration of a function, whether they've coded it or not, is the

[...]

All sorts of things go on that don't appear in the programmer's source
code : manipulating the call stack, searching the prototype chain,
garbage collection, and so on. Why aren't you complaining about those,
especially garbage collection.

That's just because I prefer to do one thing at a time ;-).

No, actually I was trying to approach this from a "can this stuff be
made easier to learn, retain and use" perspective (and, no I'm not
intending to write a book, not even produce a Javascript how-to page).

From the point of view of someone newly introduced and trying to

understand the language, does that person need to know "there's a
call-stack that's being manipulated and how it's manipulated?', or that
'the language supports recursion?', assuming that they already know
what recursion is.

Basically it comes down to whether there's a known abstraction, or
prior knowledge that can be applied, that assists in grasping the
utility and capabilty of the language. In some cases there's no
avoiding learning new terminology, or taking old terminology and
learning how it has been applied to new things.

However, in thinking things through a bit further, if you take the
triple:

(new, prototype object, function object)

does that not then abstractly represent an object replication factory?
And isn't object replication of the most fundamental operations OO
programming, Javascript in particular?

So, since it appears that I may be the only one who has a bit of a
problem with the term "constructor", is to move my approach to it up a
level, and not have to be concened about function objects and their
"constructor" nature and nomenclature at all. I'll generally be
thinking in terms of the triple and the replication that results when
employed, which should have considerably more utility in terms of
thought processes.

Consider the "constructor" terminology matter dropped (it was really
just an aside to the original post, anyway).

../rh

 

[VK]

No, actually I was trying to approach this from a "can this stuff be
made easier to learn, retain and use" perspective (and, no I'm not
intending to write a book, not even produce a Javascript how-to page).
understand the language, does that person need to know "there's a
call-stack that's being manipulated and how it's manipulated?', or that
'the language supports recursion?', assuming that they already know
what recursion is.

Basically it comes down to whether there's a known abstraction, or
prior knowledge that can be applied, that assists in grasping the
utility and capabilty of the language. In some cases there's no
avoiding learning new terminology, or taking old terminology and
learning how it has been applied to new things.

You can take me as a laboratory rat
I've been learning inheritance in JavaScript by Cars and Employee
samples (these "Hello, world" of inheritance) from Netscape docs. I
never had any problem with the idea that
var myCar = new Car();
returns *new instance of Car object*
that (myCar instanceof Car)
or that (myCar.constructor == Car).

That may be wrong, but it was perfectly logic for my mind and I assure
you that it is perfectly logic for any beginner. But even now when I am
*kind of* experienced, it still has perfect sense for me.

The only thing I'm missing is the tools to study the whole chain
*within this logic* - I need my super(). That was well on its way till
Summer 2003 when JavaScript 2.0 project suddently died. :-(

 

[ron.h.hall]

(e-mail address removed) wrote: [...]

You can take me as a laboratory rat

Already so, but thank-you for the generous, if nonetheless belated,
permission.

(I'd say that one of the reasons you seem to have encountered
difficulty in this group is that you continually try to tell everyone
how to find the cheese, when you haven't once yet found your way
through the maze).

[...]

../rh

 

[John G Harris]

(e-mail address removed) writes

However, in thinking things through a bit further, if you take the
triple:

(new, prototype object, function object)

does that not then abstractly represent an object replication factory?
And isn't object replication of the most fundamental operations OO
programming, Javascript in particular?

<snip>

Replication is an unfortunate word to use here. It implies an exact
copy, a clone. It's possible for the programmer to make the function
produce an exact copy of another object, but it's not easy and it's not
common.

Also it would be clearer to say prototype chain instead of prototype
object.

It looks like your efforts to explain javascript in terms of another
language are threatening to lead you astray.

John

 

[VK]

(I'd say that one of the reasons you seem to have encountered
difficulty in this group is that you continually try to tell everyone
how to find the cheese, when you haven't once yet found your way
through the maze).

So shall be it. Sorry for participating in a discussion for above
average IQ level. Enjoy.

 

[ron.h.hall]

(e-mail address removed) writes [...]

Replication is an unfortunate word to use here. It implies an exact
copy, a clone. It's possible for the programmer to make the function
produce an exact copy of another object, but it's not easy and it's not
common.

Not really, because I wasn't referring to cloning operations (deep or
otherwise) in the sense that you are. I was referring to the
fundamental object creation process that has 3 essential ingredients
(new, prototype object, and function object) at the programming level.

When you carry out the process of setting a prototype on a function
object and apply the new operator you create a new object. If you
repeat that process, multiple times, using the same function object,
you get a number of replica(te)s (or duplicates, or clones). And that
is a very common thing to do, except that generally arguments would be
supplied on the function invocation that provide at a minimum identity
or some other form of object differentiation in the process.

I chose to use 'replicate/replication' because clone (or duplicate)
generally implies an exact copy, objects which are indistinguishable
through test or presentation of characteristics alone. The word
'replica(te)' is in general less stringent as it can imply a close
copy.

Also it would be clearer to say prototype chain instead of prototype
object.

I would think not, John.

It looks like your efforts to explain javascript in terms of another
language are threatening to lead you astray.

That would be a mis-interpretation of approach. As motion is relative,
perhaps so is perception. ;-)

../rh

 

[ron.h.hall]

So shall be it. Sorry for participating in a discussion for above
average IQ level. Enjoy.

I can see my earlier response was a bit biting, and the humor (well OK,
I thought there was some humor) failed to salve the wound. However, the
parenthetical was actually intended to be helpful (toward seeing why
you evoke the responses you do), even if it did carry the theme --
perhaps too far.

../rh

 

[John G Harris]

(e-mail address removed) writes

When you carry out the process of setting a prototype on a function
object and apply the new operator you create a new object. If you
repeat that process, multiple times, using the same function object,
you get a number of replica(te)s (or duplicates, or clones). And that
is a very common thing to do, except that generally arguments would be
supplied on the function invocation that provide at a minimum identity
or some other form of object differentiation in the process.

<snip>

Even so, replicate still isn't appropriate for the first new as there
isn't anything to be a replica of. And in some cases objects can differ
even when there are no parameters. Think of new Date().

I would think not, John.

<snip>

If the 'prototype' property is null then there is no object, but there
is still a chain, empty as it happens.

John

 

[ron.h.hall]

(e-mail address removed) writes


<snip>

Even so, replicate still isn't appropriate for the first new as there
isn't anything to be a replica of.

I think that could be why I said "create a new object" first .

And in some cases objects can differ
even when there are no parameters. Think of new Date().

Fair enough. The function initialization could also generate random
pertubations of the object in the absence of parameters as well. That
possibility may be important to note as a detail, but it's not
particularly germane to the substance of what was put forth.

[...]

If the 'prototype' property is null then there is no object, but there
is still a chain, empty as it happens.

Hmm. The prototype property is never null (only perhaps as null object,
which is still an object) except as stopper at the programmer
inaccessible top of the internal chain. The prototype property that is
assigned may not necessarily be an object, but if not, a default object
will be substituted during the creation process.

I see no reason at all to make reference the "prototype chain", an
internal designation, when it's an object that is used at the
programming level in order to manifest a new object.

Does it have an effect on the prototype chain? Yes it does, but that's
another separate matter entirely.

../rh

 

[John G Harris]

John G Harris wrote:


I think that could be why I said "create a new object" first .

Why not use the word "create" everywhere. It's simple and honest.

Hmm. The prototype property is never null

If you do

function Thing() { ... }
Thing.prototype = null;
var t = new Thing();

then t is given the Object prototype object, call it Opo, as its
prototype. Your new object has an internal prototype property that can
never be null. However, the Opo's internal prototype property *is* null.

So, there is an object with a null internal prototype property, but it's
an object created by internal magic not by the kind of constructor we
can write.

(only perhaps as null object,
which is still an object)

No. In javascript Null and Object are different types. In C, C++, and
Java, null is a pointer or reference with a special value. In javascript
null is the only value belonging to the Null type. It's not a reference,
nor is it a warped object.

except as stopper

Since every prototype chain ends at a null, by definition, I wouldn't
call it exceptional.

I see no reason at all to make reference the "prototype chain", an
internal designation, when it's an object that is used at the
programming level in order to manifest a new object.

Does it have an effect on the prototype chain? Yes it does, but that's
another separate matter entirely.

Let's agree to differ here. Your view looks along the prototype chain so
that the first prototype object hides all the others.

My view looks from the side so that all the prototype objects can be
seen. This has the advantage that I can see which functions are hidden
by objects closer to the front of the chain. More likely, it shows which
haven't been hidden but should have been.

John

 

[ron.h.hall]

Why not use the word "create" everywhere. It's simple and honest.

By implication, I gather there's something you find complex and
dishonest about 'replicate'. These are objects, not counterfeit (money,
paintings, etc.) being passed off as the real thing to unsuspecting
victims. They are completely legitimate, as is the process, as is the
term 'replicate'.

Replication is a creation process, but it's a process that doesn't
simply create, it produces copies. And that's the answer to your "Why?"
-- some words add meaning, and therefore are highly preferable to terms
that are more general in nature.

Is this really rocket science to you, as you seem to be making it out
to be, or do you just greatly enjoy the keep of a pot well stirred? ;-)

If you do

function Thing() { ... }
Thing.prototype = null;
var t = new Thing();

then t is given the Object prototype object, call it Opo, as its
prototype. Your new object has an internal prototype property that can
never be null. However, the Opo's internal prototype property *is* null.

So, there is an object with a null internal prototype property, but it's
an object created by internal magic not by the kind of constructor we
can write.



No. In javascript Null and Object are different types. In C, C++, and
Java, null is a pointer or reference with a special value. In javascript
null is the only value belonging to the Null type. It's not a reference,
nor is it a warped object.

In this you're correct. I had forgotten that 'null' is a primitive, in
spite of the fact that 'typeof null' returns 'object'. However, the
fact that 'null' is not an object is the reason that 'Opo', as you've
chosen to call it, is substituted.

Since every prototype chain ends at a null, by definition, I wouldn't
call it exceptional.

Then why did you bother to raise it as an issue in the first place?
(No, I really don't want an answer, the questions herein are all
rhetorical.)

Let's agree to differ here. Your view looks along the prototype chain so
that the first prototype object hides all the others.

Gaaaccck! Here we were just about to agree to differ , and you
follow up with presentation of yet another completely unfathomable
misconception. Great bait, but I'm not biting.

My view looks from the side so that all the prototype objects can be
seen. This has the advantage that I can see which functions are hidden
by objects closer to the front of the chain. More likely, it shows which
haven't been hidden but should have been.

I think it would be most appropriate for me to say at this time, as at
the very least one of us is moving on (namely me ;-)), that I'm moving
on.

../rh