Crockford's Prototypal Inheritance Function
timothytoe
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.
tomtom....@gmail.com
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
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/comp.lang.javascript/browse_frm/thread/fc74c84dfefe26a0/c63eae48f41921cb?hl=en&lnk=gst&q=+Crockford%27s+JavaScript+OOP+system#c63eae48f41921cb
>
--
Rob
Stevo
> I understand JavaScript objects well enough to make objects and add
> prototype functions to them later on.
>
> 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:
Stevo
> timothytoe wrote:
>> 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.
> beget in there, although I don't know which of the 4 videos it was:
>
> http://developer.yahoo.com/yui/theater/
Make that 8 videos. There are 4 that cover Javascript in general, 3 that
are advanced Javascript, and 1 that's about Ajax. I recommend watching
them all.
Joost Diepenmaat
> 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.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
timothytoe
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.
John G Harris
<snip>
> // 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
--
John Harris
John G Harris
wrote:
>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?
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
--
John Harris
timothytoe
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.
Joost Diepenmaat
> 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.
timothytoe
Thanks. Good timing on that blog entry. :-)
Joost Diepenmaat
> Thanks. Good timing on that blog entry. :-)
As long as I get some payed work out of it, I'll consider it time well
spent :-)
John G Harris
Diepenmaat wrote:
<snip>
>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
--
John Harris
Joost Diepenmaat
> 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.
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.
Peter
John G Harris
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
--
John Harris
Joost Diepenmaat
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).
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.
Thomas 'PointedEars' Lahn
> On Feb 14, 12:37 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>> 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
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