Crockford's Prototypal Inheritance Function

T

timothytoe

I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Despite my success in getting programs written, I keep coming back to
Crockford's paper on prototypal inheritance, in which he decides that
all that work he did earlier to bolt a classical inheritance system
onto JavaScript was missing the point.

http://javascript.crockford.com/prototypal.html

It's an interesting paper, but he just drops a couple functions on us
and acts as if anyone reading the paper should go ahhh! I've read the
paper many times and the point eludes me. Just what do these functions
give me that I don't already have?

function object(o) {
function F() {}
F.prototype = o;
return new F();
}

and

Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();
};

newObject = oldObject.begetObject();

I'm assuming that if I saw an example of one in use, I'd get that
elusive aha feeling.

Can someone please explain the clever bits? Or give me an example and
explain how the example is helped by the function.

He even drops one of these into a Powerpoint slideshow he has. One its
own slide. All alone. As if it requires no explanation.

If you were planning to help a dolt or a dope understand one thing
today, let that dope be me, and let that thing be this.
 
T

tomtom.wozniak

I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Despite my success in getting programs written, I keep coming back to
Crockford's paper on prototypal inheritance, in which he decides that
all that work he did earlier to bolt a classical inheritance system
onto JavaScript was missing the point.

http://javascript.crockford.com/prototypal.html

It's an interesting paper, but he just drops a couple functions on us
and acts as if anyone reading the paper should go ahhh! I've read the
paper many times and the point eludes me. Just what do these functions
give me that I don't already have?

function object(o) {
function F() {}
F.prototype = o;
return new F();
}

and

Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();

};

newObject = oldObject.begetObject();

I'm assuming that if I saw an example of one in use, I'd get that
elusive aha feeling.

Can someone please explain the clever bits? Or give me an example and
explain how the example is helped by the function.

He even drops one of these into a Powerpoint slideshow he has. One its
own slide. All alone. As if it requires no explanation.

If you were planning to help a dolt or a dope understand one thing
today, let that dope be me, and let that thing be this.

Using the few simple lines of begetObject, any new object (function)
you create can inherit all of the old object's methods but you're free
to mutate your new object at any time.

Here's an example I found to help explain:

// Ripped from http://www.amundsen.com/blog/archives/395
<script>
// extend Object to ease prototypal inheritance
Object.prototype.begetObject = function() {
function F() {}
F.prototype = this;
return new F();
};
// simple class
function Dog(name) {
this.name = (name!==undefined?name:'dog');
};
// smarter class
function HungryDog(o) {
var bo = o.begetObject();
bo.eat = function() { alert('eating...'); }
return bo;
};
// even smarter class
function TrainedDog(o) {
var bo = o.begetObject();
bo.sit = function() { alert('sitting...'); }
return bo;
};
// show it all works
var td = new TrainedDog(new HungryDog(new Dog('marvin')));
td.sit();
td.eat();
alert(td.name);
</script>

Basically, add whatever extra methods you like to any object.

Does this help explain or did I miss your question entirely?

Cheers!

-Tom Woz
 
R

RobG

I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Despite my success in getting programs written, I keep coming back to
Crockford's paper on prototypal inheritance, in which he decides that
all that work he did earlier to bolt a classical inheritance system
onto JavaScript was missing the point.

http://javascript.crockford.com/prototypal.html

It's an interesting paper, but he just drops a couple functions on us
and acts as if anyone reading the paper should go ahhh! I've read the
paper many times and the point eludes me. Just what do these functions
give me that I don't already have?

function object(o) {
function F() {}
F.prototype = o;
return new F();
}

and

Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();

};

newObject = oldObject.begetObject();

They are his a way of creating new objects with prototype inheritance
without using the new operator.

I'm assuming that if I saw an example of one in use, I'd get that
elusive aha feeling.

Can someone please explain the clever bits? Or give me an example and
explain how the example is helped by the function.

Try the following thread:

Subject: Crockford's JavaScript OOP system
<URL:
http://groups.google.com.au/group/c...ford's+JavaScript+OOP+system#c63eae48f41921cb
 
S

Stevo

timothytoe said:
I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Can someone please explain the clever bits? Or give me an example and
explain how the example is helped by the function.

He even drops one of these into a Powerpoint slideshow he has. One its
own slide. All alone. As if it requires no explanation.

Have you tried watching his video lectures? I recall him mentioning
beget in there, although I don't know which of the 4 videos it was:

http://developer.yahoo.com/yui/theater/
 
J

Joost Diepenmaat

timothytoe said:
Just what do these functions give me that I don't already have?

These functions just make it more convenient to set up the *actual*
mechanism that does "inheritance" and "instance-of" relations in
javascript: the prototype chain. Note that the prototype-lookup
mechanism only resembles the more well-known, class-based inheritance
and instance-of relations if you keep your eyes half-closed.

I've argued here before that javascript's constructor functions are if
not missing the point then at least quite confusing if you expect them
to work like classes. IMO the main point in favor of the object() and
begetObject() functions is that they get the constructor confusion out
of the way.
 
T

timothytoe

OK. I get it now. I can get rid of my constructor in my main code. I
just read his article again and it made sense. Apparently, I'm not
someone who can grasp an idea without an example. Thanks. All of you
helped.
 
J

John G Harris

On Sun, 10 Feb 2008 at 20:53:58, in comp.lang.javascript, wrote:
// show it all works
var td = new TrainedDog(new HungryDog(new Dog('marvin')));
td.sit();
td.eat();
alert(td.name);
</script>

That's not a nice thing to do. What happens when you make the mistake of
writing
var td1 = new TrainedDog(new Dog('marvin'));

It's better to hide the complications of construction inside a function
so the user can write what he's thinking, namely
var td2 = new TrainedDog('marvin');

Or did you want the choice -
var td3 = new TrainedAndHungryDog('marvin');
or
var td4 = new TrainedButNotHungryDog('marvin');

John
 
J

John G Harris

I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Despite my success in getting programs written, I keep coming back to
Crockford's paper on prototypal inheritance, in which he decides that
all that work he did earlier to bolt a classical inheritance system
onto JavaScript was missing the point.

http://javascript.crockford.com/prototypal.html

It's an interesting paper, but he just drops a couple functions on us
and acts as if anyone reading the paper should go ahhh! I've read the
paper many times and the point eludes me. Just what do these functions
give me that I don't already have?
<snip>

Remember that you don't *have* to make javascript look like another
language. Why not do things the javascript way for a while. When you're
familiar with this you can decide how to do things more easily and more
clearly, and become famous when you publish this new way. Or infamous if
other people disagree about the ease and clarity :)

John
 
T

timothytoe

>I understand JavaScript objects well enough to make objects and add


<snip>

Remember that you don't *have* to make javascript look like another
language. Why not do things the javascript way for a while. When you're
familiar with this you can decide how to do things more easily and more
clearly, and become famous when you publish this new way. Or infamous if
other people disagree about the ease and clarity :)

John

As far as I can tell, I've been doing things the JavaScript way. I
just wanted to know what the hell Crockford was talking about.
 
J

Joost Diepenmaat

timothytoe said:
As far as I can tell, I've been doing things the JavaScript way. I
just wanted to know what the hell Crockford was talking about.

Just to give you some examples of what can go wrong with the IMO nasty
"new constructor()" syntax:

http://joost.zeekat.nl/constructors-considered-mildly-confusing.html

The advantage of Crockford's functions is that they give up any pretense
that constructors can be referred to later or act like classes or any of
that nonsense.

Cheers,
J.
 
J

John G Harris

Just to give you some examples of what can go wrong with the IMO nasty
"new constructor()" syntax:

http://joost.zeekat.nl/constructors-considered-mildly-confusing.html
<snip>


There's something not quite right in your notes. You say
"Also note that the [[Prototype]] chain for each object ends up at
Object.prototype."
In fact it always ends at the *original* Object.prototype. If you
replace Object.prototype with your own object you will still find that
the modified chain ends with the *original* Object.prototype.

Likewise, when you say
"Object.prototype's [[Prototype]] is actually null indicating that
it's the end of the chain."
you are really talking about the *original* Object.prototype.

John
 
J

Joost Diepenmaat

John G Harris said:
There's something not quite right in your notes. You say
"Also note that the [[Prototype]] chain for each object ends up at
Object.prototype."
In fact it always ends at the *original* Object.prototype. If you
replace Object.prototype with your own object you will still find that
the modified chain ends with the *original* Object.prototype.

Likewise, when you say
"Object.prototype's [[Prototype]] is actually null indicating that
it's the end of the chain."
you are really talking about the *original* Object.prototype.

That's true. I didn't mention it, because you can overwrite basically
all of those "constants" in javascript, but for completeness it's
probably best if I add some more info on that.

Thanks for the feedback,

Joost.
 
P

Peter Michaux

I understand JavaScript objects well enough to make objects and add
prototype functions to them later on.

Despite my success in getting programs written, I keep coming back to
Crockford's paper on prototypal inheritance, in which he decides that
all that work he did earlier to bolt a classical inheritance system
onto JavaScript was missing the point.

http://javascript.crockford.com/prototypal.html

It's an interesting paper, but he just drops a couple functions on us
and acts as if anyone reading the paper should go ahhh! I've read the
paper many times and the point eludes me. Just what do these functions
give me that I don't already have?

function object(o) {
function F() {}
F.prototype = o;
return new F();
}

and

Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();

};

newObject = oldObject.begetObject();

You may find this thread handy as it talks about the same clone
function.

<URL:
http://groups.google.com/group/comp...st&q=richard+lasse+crockford#c63eae48f41921cb>

Peter
 
J

John G Harris

John G Harris said:
There's something not quite right in your notes. You say
"Also note that the [[Prototype]] chain for each object ends up at
Object.prototype."
In fact it always ends at the *original* Object.prototype. If you
replace Object.prototype with your own object you will still find that
the modified chain ends with the *original* Object.prototype.

Likewise, when you say
"Object.prototype's [[Prototype]] is actually null indicating that
it's the end of the chain."
you are really talking about the *original* Object.prototype.

That's true. I didn't mention it, because you can overwrite basically
all of those "constants" in javascript, but for completeness it's
probably best if I add some more info on that.

Thanks for the feedback,

Joost.

On second thoughts, after re-reading the small print, I see that
object.prototype is ReadOnly. Therefore it's not possible to make
object.prototype a chain that is longer than one object.

In that case, why the hell does the word 'original' appear in so many
places in the standard? It appears to be meaningless.

John
 
J

Joost Diepenmaat

John G Harris said:
On second thoughts, after re-reading the small print, I see that
object.prototype is ReadOnly. Therefore it's not possible to make
object.prototype a chain that is longer than one object.

In that case, why the hell does the word 'original' appear in so many
places in the standard? It appears to be meaningless.

The host systems are explicitely allowed to change those properties. Why
they'd ever do that, I really don't know. I tried to explain a bit in my
update of the text a couple of hours ago (same URL, reload the page).
 
V

VK

On second thoughts, after re-reading the small print, I see that
object.prototype is ReadOnly. Therefore it's not possible to make
object.prototype a chain that is longer than one object.

In that case, why the hell does the word 'original' appear in so many
places in the standard? It appears to be meaningless.

Because any prototype is read-only except NN and Gecko where they keep
__proto__ accessor for whatever reasons. prototype is not in function-
constructor, it is in instances created by that function-constructor.
This way Object.prototype is null, but any "new Object()" will get
methods of the original prototype provided by Object.
 
T

Thomas 'PointedEars' Lahn

VK said:
Because any prototype is read-only

Wrong. The `prototype' *property* of all *built-in objects* has the
attribute ReadOnly.
except NN and Gecko

Pure nonsense.

Netscape Navigator is a browser, not a script engine. SpiderMonkey, that it
uses as script engine, does not allow overwriting the `prototype' property
value of built-in objects, at least not in version 4.78.

And once more, especially for you: Gecko is a *layout engine*, _not_ a
script engine. SpiderMonkey, the most common JavaScript script engine of
user agents that also have Gecko as their layout engine, does not allow
overwriting the `prototype' property value of built-in objects.
where they keep __proto__ accessor for whatever reasons.

The proprietary `__proto__' property that JavaScript provides has nothing to
do with that.
prototype is not in function-constructor, it is in instances created by
that function-constructor. This way Object.prototype is null, but any
"new Object()" will get methods of the original prototype provided by
Object.

Again you are not making any sense, and the rest of what you are saying
is utterly wrong. If only you would refrain from boldly posting your
incoherent gibberish and smattering "explanations", if that.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top