By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,742 Members | 2,026 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,742 IT Pros & Developers. It's quick & easy.

simply super

P: n/a
Hello list. This is my first message and it's nothing needful but
rather playful. I'd just like to hear some thoughts on something I
consider to be a curiosity of javascript usage. I've seen a lot of
folks looking to implement some kind of super-like functionality in
javascript and it's usually baked into some larger effort of emulating
classes. However if you really need* that type of functionality why
not get it like so:

//assuming that foo has its own sayIt property and a sayIt property in
its prototype chain
var backup = foo.sayIt;
delete foo.sayIt;
foo.sayIt(); // now, delegates up the chain
foo.sayIt = backup;

So you can see that it's easy enough to make use of javascript's built-
in property delegation/lookup to emulate super-like functionality. And
if you wanted to make easier use of that pattern:

foo.supe = function( prop ){
var backup = this[prop];
delete this[prop];
if( typeof this[prop] == 'function' ){
var r = this[prop]();
}else{
var r = this[prop];
}
this[prop] = backup;
return r;
};

foo.supe('sayIt');

So there's an example of a general purpose super-like function. It
doesn't include argument passing even though that's entirely possible.
So is that not the simplest way of getting super-like functionality?
If anyone has some feedback I'd love to hear it. I hope I've been
clear.

You can also see a more complete working example of the code at:
http://highlight.tumblr.com/post/55510055/

* I haven't personally needed super-like functionality in my
javascript coding. Apparently, neither has Crockdolf as you can now
read at the bottom of his scroll of classical javascript teachings:
"I have been writing JavaScript for 8 years now, and I have never once
found need to use an uber function. The super idea is fairly important
in the classical pattern, but it appears to be unnecessary in the
prototypal and functional patterns. I now see my early attempts to
support the classical model in JavaScript as a mistake."
from: http://javascript.crockford.com/inheritance.html

--
thanks for reading,
m

Oct 29 '08 #1
Share this Question
Share on Google+
25 Replies


P: n/a
On Oct 29, 2:58*pm, "dylan m. austin" <mr.f...@gmail.comwrote:
Hello list. This is my first message and it's nothing needful but
rather playful. I'd just like to hear some thoughts on something I
consider to be a curiosity of javascript usage. I've seen a lot of
folks looking to implement some kind of super-like functionality in
javascript and it's usually baked into some larger effort of emulating
classes. However if you really need* that type of functionality why
not get it like so:
The larger effort is largely a misguided attempt to make JavaScript
work like Java (or other languages with classical inheritance
patterns.)
>
//assuming that foo has its own sayIt property and a sayIt property in
its prototype chain
var backup = foo.sayIt;
delete foo.sayIt;
foo.sayIt(); // now, delegates up the chain
foo.sayIt = backup;
Yikes.

https://developer.mozilla.org/En/Cor.../Function/Call
>
So you can see that it's easy enough to make use of javascript's built-
in property delegation/lookup to emulate super-like functionality. And
if you wanted to make easier use of that pattern:

foo.supe = function( prop ){
* var backup = this[prop];
* delete this[prop];
* if( typeof this[prop] == 'function' ){
* * var r = this[prop]();
* }else{
* * var r = this[prop];
* }
* this[prop] = backup;
* return r;

};

foo.supe('sayIt');

So there's an example of a general purpose super-like function. It
doesn't include argument passing even though that's entirely possible.
Of course.
So is that not the simplest way of getting super-like functionality?
If anyone has some feedback I'd love to hear it. I hope I've been
clear.
It is easy enough to invoke a method of the "super" object. What is
trickier is doing it without mentioning the object by name.
>
You can also see a more complete working example of the code at:http://highlight.tumblr.com/post/55510055/

* I haven't personally needed super-like functionality in my
javascript coding. Apparently, neither has Crockdolf as you can now
read at the bottom of his scroll of classical javascript teachings:
"I have been writing JavaScript for 8 years now, and I have never once
found need to use an uber function. The super idea is fairly important
in the classical pattern, but it appears to be unnecessary in the
prototypal and functional patterns. I now see my early attempts to
support the classical model in JavaScript as a mistake."
from:http://javascript.crockford.com/inheritance.html
Too bad the Prototype crowd hasn't read this. Would you post a link
at the bottom of one of their blogs?
Oct 30 '08 #2

P: n/a
Yikes.
>
https://developer.mozilla.org/En/Cor...ference/Global...
Sure, good ol' call. I'm glad you mention it but to use it you've got
to find your own way reference the function you want to call. As you
also wrote:
It is easy enough to invoke a method of the "super" object. *What is
trickier is doing it without mentioning the object by name.
So that's exactly what temporary removal of the local property
achieves, you don't have to reference the 'super' object.
Too bad the Prototype crowd hasn't read this. Would you post a link
at the bottom of one of their blogs?
The quote from Crockford's page? I can't be sure they haven't read it
and besides I'm not familiar with the crowd or their blogs.
Oct 30 '08 #3

P: n/a
On Oct 30, 1:11*pm, "dylan m. austin" <mr.f...@gmail.comwrote:
Yikes.
https://developer.mozilla.org/En/Cor...ference/Global...

Sure, good ol' call. I'm glad you mention it but to use it you've got
to find your own way reference the function you want to call. As you

also wrote:
It is easy enough to invoke a method of the "super" object. *What is
trickier is doing it without mentioning the object by name.

So that's exactly what temporary removal of the local property
achieves, you don't have to reference the 'super' object.
In a very clumsy way. I wouldn't recommend that method.
Oct 30 '08 #4

P: n/a
On Oct 30, 8:10*pm, David Mark <dmark.cins...@gmail.comwrote:
>
In a very clumsy way. *
Crockford does mention exactly this in one of his videos, when while
explaining the prototype chain somebody asks "What happens if a
property is deleted from an instance ?"

<http://developer.yahoo.com/yui/theater/>

I wouldn't recommend that method.
Which would you recommend ?

--
Jorge.
Oct 30 '08 #5

P: n/a
On Oct 30, 3:46*pm, Jorge <jo...@jorgechamorro.comwrote:
On Oct 30, 8:10*pm, David Mark <dmark.cins...@gmail.comwrote:
In a very clumsy way. *

Crockford does mention exactly this in one of his videos, when while
explaining the prototype chain somebody asks "What happens if a
property is deleted from an instance ?"

<http://developer.yahoo.com/yui/theater/>
I wouldn't recommend that method.

Which would you recommend ?
I agree with the Crockford quote. Trying to implement classical
inheritance patterns with an ECMAScript-based language is a waste of
time.
Oct 30 '08 #6

P: n/a
Jorge meinte:
On Oct 30, 8:10 pm, David Mark <dmark.cins...@gmail.comwrote:
>In a very clumsy way.

Crockford does mention exactly this in one of his videos, when while
explaining the prototype chain somebody asks "What happens if a
property is deleted from an instance ?"
But does he endorse it?

Gregor
Oct 30 '08 #7

P: n/a
On Oct 29, 11:58 am, "dylan m. austin" <mr.f...@gmail.comwrote:
* I haven't personally needed super-like functionality in my
javascript coding. Apparently, neither has Crockdolf as you can now
read at the bottom of his scroll of classical javascript teachings:
"I have been writing JavaScript for 8 years now, and I have never once
found need to use an uber function. The super idea is fairly important
in the classical pattern, but it appears to be unnecessary in the
prototypal and functional patterns. I now see my early attempts to
support the classical model in JavaScript as a mistake."
from:http://javascript.crockford.com/inheritance.html
I don't see how the prototypal-based or class-based systems have
anything to do with needing super-like functionality. These are
unrelated issues.

Peter
Oct 31 '08 #8

P: n/a
On Oct 29, 5:30 pm, David Mark <dmark.cins...@gmail.comwrote:
The larger effort is largely a misguided attempt to make JavaScript
work like Java (or other languages with classical inheritance
patterns.)
I disagree. Classes are a pattern. Prototypes are a pattern. Each is
useful in different situations. It just so happens that JavaScript has
some in-language support for the prototype style. JavaScript is very
capable of expressing the class style because JavaScript functions are
lambdas (more or less.) "Structure and Interpretation of Computer
Programs" has many elegant uses of the class style in Scheme and
Scheme doesn't have any particular language support for any OOP
programming style. Lambdas are all it takes. To throw away the option
of using the class style where it is appropriate just because
JavaScript doesn't have bits os syntax sugar for it would be a shame.

It looks like the next major revision of ECMAScript will have some
sort of class construct in it. The interesting thing about how the
committee seems to be designing it is that these classes are just
sugar for the prototype-based system.

Peter
Oct 31 '08 #9

P: n/a
On 30 oct, 16:16, Gregor Kofler <use...@gregorkofler.atwrote:
Crockford does mention exactly this in one of his videos, when while
explaining the prototype chain somebody asks "What happens if a
property is deleted from an instance ?"

But does he endorse it?

Gregor
It's not likely. Did you see the excerpt from his writing included at
the bottom of the first message in this thread?
Oct 31 '08 #10

P: n/a
On Oct 31, 12:22*am, Peter Michaux <petermich...@gmail.comwrote:
On Oct 29, 5:30 pm, David Mark <dmark.cins...@gmail.comwrote:
The larger effort is largely a misguided attempt to make JavaScript
work like Java (or other languages with classical inheritance
patterns.)

I disagree. Classes are a pattern. Prototypes are a pattern. Each is
useful in different situations. It just so happens that JavaScript has
some in-language support for the prototype style. JavaScript is very
capable of expressing the class style because JavaScript functions are
lambdas (more or less.) "Structure and Interpretation of Computer
Certainly it is.
Programs" has many elegant uses of the class style in Scheme and
Scheme doesn't have any particular language support for any OOP
programming style. Lambdas are all it takes. To throw away the option
of using the class style where it is appropriate just because
JavaScript doesn't have bits os syntax sugar for it would be a shame.
I don't know. I don't regularly use languages with classes.
JavaScript is my most used language and I just never found the need to
simulate classes to do anything. Now as this thread has been largely
about calling a "super method", I agree with your comment that it
isn't relegated to classical inheritance patterns. That I do use and
due to the well-documented clumsiness of using constructors, it is
always a little awkward. I just see classes as even more awkward for
ECMAScript.
>
It looks like the next major revision of ECMAScript will have some
sort of class construct in it. The interesting thing about how the
committee seems to be designing it is that these classes are just
sugar for the prototype-based system.
I'm not paying any attention to them. If they ever produce a
specification, I'll read it.
Oct 31 '08 #11

P: n/a
On Oct 30, 10:00*pm, David Mark <dmark.cins...@gmail.comwrote:
I don't know. *I don't regularly use languages with classes.
JavaScript is my most used language and I just never found the need to
simulate classes to do anything. *Now as this thread has been largely
about calling a "super method", I agree with your comment that it
isn't relegated to classical inheritance patterns. *That I do use and
due to the well-documented clumsiness of using constructors, it is
always a little awkward.
It sure is awkward, unfortunately.
I just see classes as even more awkward for
ECMAScript.
[snip]
I'm not paying any attention to them. *If they ever produce a
specification, I'll read it.
I'd be willing to bet they at least get 3.1 out in 2009.

http://wiki.ecmascript.org/doku.php?..._working_draft

Peter
Oct 31 '08 #12

P: n/a
On 30 oct, 22:22, Peter Michaux <petermich...@gmail.comwrote:
I disagree. Classes are a pattern. Prototypes are a pattern. Each is
useful in different situations. It just so happens that JavaScript has
some in-language support for the prototype style. JavaScript is very
capable of expressing the class style because JavaScript functions are
lambdas (more or less.) "Structure and Interpretation of Computer
Programs" has many elegant uses of the class style in Scheme and
Scheme doesn't have any particular language support for any OOP
programming style. Lambdas are all it takes.
I'll bet classical style works quite well for a ton of situations.
Think of all the real live working code written with it. Still, a lot
of effort has probably been spent in classical approaches with
javascript in situations where it might not be necessary or even best.

It'd be interesting to see those Scheme/lambda concepts from the
source you mention applied to javascript. You haven't already covered
something like that in your blog have you? Or have you seen anything
like that around?
Oct 31 '08 #13

P: n/a
On Oct 30, 10:38 pm, "dylan m. austin" <mr.f...@gmail.comwrote:
On 30 oct, 22:22, Peter Michaux <petermich...@gmail.comwrote:
I disagree. Classes are a pattern. Prototypes are a pattern. Each is
useful in different situations. It just so happens that JavaScript has
some in-language support for the prototype style. JavaScript is very
capable of expressing the class style because JavaScript functions are
lambdas (more or less.) "Structure and Interpretation of Computer
Programs" has many elegant uses of the class style in Scheme and
Scheme doesn't have any particular language support for any OOP
programming style. Lambdas are all it takes.

I'll bet classical style works quite well for a ton of situations.
Think of all the real live working code written with it. Still, a lot
of effort has probably been spent in classical approaches with
javascript in situations where it might not be necessary or even best.

It'd be interesting to see those Scheme/lambda concepts from the
source you mention applied to javascript. You haven't already covered
something like that in your blog have you? Or have you seen anything like that around?
No I haven't seen the SICP examples translated to JavaScript. If you
read SICP, which I whole heartedly recommend as the best reading a
JavaScript programmer could do, you won't have any trouble translating
the OOP examples to JavaScript.

The only real issue with the way OOP is done in SICP, when translated
to JavaScript, is performance. Using the built-in message dispatch is
faster than each object being its own dispatch function. For example,
in JavaScript you might have

var o = {
foo: function() {return 1;},
bar: function() {return 2;}
};

o.foo();
o.bar();

In the SICP style, an object is a function of its messages. In a
really naive use of the SICP style it might be

var o = function(message) {
if (message == 'foo') {
return 1;
}
else if (message == 'bar'){
return 2;
}
else {
throw new Error('unknown message');
}
};

o('foo');
o('bar');

In the above the if--else-if conditionals need to be tested in
sequence (grows linearly in time with more messages) which is slower
than in the first version using dot notation for method dispatch.

A slightly more sophisticated implementation of the SICP style
taylored to JavaScript might be

var o = (function() {

var messages = {
foo: function() {
return 1;
},
bar: function() {
return 2;
}
};

return function(message) {
var args = Array.prototype.splice(arguments, 0);
args.shift();
return messages[message].apply(null, args);
};

})();

o('foo');
o('bar');

In this example a hashing algorithm probably finds the appropriate
property of the messages object and that is roughly constant in time.

----

You can see that in the SICP style, the object is its own dispatch
function. This makes all sorts of things possible. For example, method
missing is easy

return function(message) {
var args = Array.prototype.splice(arguments, 0);
args.shift();
if (messages.hasOwnProperty(message)) {
return messages[message].apply(null, args);
}
else {
return methodMissing.apply(null, args);
}
};

o('foo');
o('asdf'); // uses methodMissing

----

Performance is important and so having objects be their own dispatch
functions should only be used when necessary.

----

The unfortunate part is people are also caught up about syntax. I
don't really care if I write any of the following three

o.setProp(5);
o.prop = 5;
o('prop=', 5);

because I'd rather be writing

(o 'prop= 5)

anyway because then hygenic macros would be available :-)

The semantics of the above four could all be the same. That is, a
setter function runs.

----

If you like this sort of thing I think you would enjoy SICP and you
get to learn Scheme along the way which is a beautiful thing.

http://www.amazon.com/Structure-Inte...5432918&sr=8-1

My favorite programming book.

Peter
Oct 31 '08 #14

P: n/a
dylan m. austin meinte:
It's not likely. Did you see the excerpt from his writing included at
the bottom of the first message in this thread?
I'm pretty sure he doesn't. Though Jorge's post left an impression, as
Crockford "advocates" this approach.

Gregor
Oct 31 '08 #15

P: n/a
On Oct 31, 10:43*am, Gregor Kofler <use...@gregorkofler.atwrote:
dylan m. austin meinte:
It's not likely. Did you see the excerpt from his writing included at
the bottom of the first message in this thread?

I'm pretty sure he doesn't. Though Jorge's post left an impression, as
Crockford "advocates" this approach.
That wasn't my intention. But this is unrelated to the classical vs
prototypical inheritance debate, as Michaux has noted already.

If we leave that debate aside, the answer to dylan (the OP) shouldn't
be just "what a clumsy method" "I wouldn't recommend it" kind of "junk
junk !", unless you tell as well what a better way of doing it is.

I'd repeat the question I made to David Mark: which method would you
use ?

--
Jorge.
Oct 31 '08 #16

P: n/a
Jorge wrote:
I'd repeat the question I made to David Mark: which method would you
use ?
Here's a couple of blog posts. I'm surprised that no-one have mentioned
John Resig's yet.

http://ejohn.org/blog/simple-javascript-inheritance/
http://jonathanfine.wordpress.com/20...in-javascript/
Here's an extract of the key piece of code in my blog:
====
var sup = function(klass, name){
return function(){
var fn = klass.proto[name];
return Function.call.apply(fn, arguments);
};
};
====

It may take you white to understand Function.call.apply.

--
Jonathan
Oct 31 '08 #17

P: n/a
On 31 oct, 05:29, Jorge <jo...@jorgechamorro.comwrote:
If we leave that debate aside, the answer to dylan (the OP) shouldn't
be just "what a clumsy method" "I wouldn't recommend it" kind of "junk
junk !", unless you tell as well what a better way of doing it is.

I'd repeat the question I made to David Mark: which method would you
use ?
Thanks Jorge. I've gotta second you on this. For those that have used
the super-like concept at some point, how was it implemented?

We've seen a message from David Mark admitting use of something super-
ish. I inferred that it might make use of constructor references and
therefore would differ considerably from the pattern I presented.
Though he made it sound as if it's still a bit awkward. Better than
clumsy, right ;) Let's see it.

Thanks everyone. I'm enjoying this discussion even if we derail a bit.
Oct 31 '08 #18

P: n/a
On Oct 31, 7:29*am, Jorge <jo...@jorgechamorro.comwrote:
On Oct 31, 10:43*am, Gregor Kofler <use...@gregorkofler.atwrote:
dylan m. austin meinte:
It's not likely. Did you see the excerpt from his writing included at
the bottom of the first message in this thread?
I'm pretty sure he doesn't. Though Jorge's post left an impression, as
Crockford "advocates" this approach.

That wasn't my intention. But this is unrelated to the classical vs
prototypical inheritance debate, as Michaux has noted already.

If we leave that debate aside, the answer to dylan (the OP) shouldn't
be just "what a clumsy method" "I wouldn't recommend it" kind of "junk
junk !", unless you tell as well what a better way of doing it is.

I'd repeat the question I made to David Mark: which method would you
use ?
I answered that (the call method.)
Oct 31 '08 #19

P: n/a
On Oct 31, 8:16*am, Jonathan Fine <J.F...@open.ac.ukwrote:
Jorge wrote:
I'd repeat the question I made to David Mark: which method would you
use ?

Here's a couple of blog posts. *I'm surprised that no-one have mentioned
John Resig's yet.
Why? Comic relief?

[snip]
Oct 31 '08 #20

P: n/a
On 31 oct, 14:17, David Mark <dmark.cins...@gmail.comwrote:
On Oct 31, 8:16*am, Jonathan Fine <J.F...@open.ac.ukwrote:
Jorge wrote:
I'd repeat the question I made to David Mark: which method would you
use ?
Here's a couple of blog posts. *I'm surprised that no-one have mentioned
John Resig's yet.

Why? *Comic relief?

[snip]
Hehe, I don't know why I get a kick of out of the resig-bashing. It's
probably not the best of behavior.

I too haven't been following the latest work on the ECMAScript
specifications but here's one entry I found interesting on Johh's
blog:
http://ejohn.org/blog/objectgetprototypeof/

It covers the Object.getPrototypeOf method they've come up with for
ECMAScript 3.1 and shows a basic example of getting super-
functionality with it. I'll reproduce that here:
function Person(){}

Person.prototype.kick = function(type){
alert(type + " kick!");
}

function Norris(){}

// Inherit properties from Person
Norris.prototype = new Person();

Norris.prototype.kick = function(){
Object.getPrototypeOf(this).kick("Roundhouse");
};

His example isn't dependent on correct binding of the 'super' call.
For a more real-world use it would probably need the use of 'call',
like so:

Norris.prototype.kick = function(){
Object.getPrototypeOf(this).kick.call(this,"Roundh ouse");
};

So how about that, David? You can use call and avoid constructor
reference clumsiness. Pretty super or what? If you are coding for 3.1
and up implementations, anyway.
Oct 31 '08 #21

P: n/a
On Oct 31, 4:44*pm, "dylan m. austin" <mr.f...@gmail.comwrote:
On 31 oct, 14:17, David Mark <dmark.cins...@gmail.comwrote:
On Oct 31, 8:16*am, Jonathan Fine <J.F...@open.ac.ukwrote:
Jorge wrote:
I'd repeat the question I made to David Mark: which method would you
use ?
Here's a couple of blog posts. *I'm surprised that no-one have mentioned
John Resig's yet.
Why? *Comic relief?
[snip]

Hehe, I don't know why I get a kick of out of the resig-bashing. It's
probably not the best of behavior.
It is his lousy scripts, blog entries, books, etc. that get the well-
deserved criticism here. As for him as a person, he is an idiot, but
that is OT.
>
I too haven't been following the latest work on the ECMAScript
specifications but here's one entry I found interesting on Johh's
blog:http://ejohn.org/blog/objectgetprototypeof/
I just can't see wasting five minutes of my life to read more of his
nonsense.
Oct 31 '08 #22

P: n/a
dylan m. austin wrote:
[...]
http://ejohn.org/blog/objectgetprototypeof/

It covers the Object.getPrototypeOf method they've come up with
for ECMAScript 3.1 and shows a basic example of getting super-
functionality with it. I'll reproduce that here:
function Person(){}

Person.prototype.kick = function(type){
alert(type + " kick!");
}

function Norris(){}

// Inherit properties from Person
Norris.prototype = new Person();
Obviously, as it has been explained numerous times before, that is _not_ the
proper way to emulate class-based inheritance in a prototype-based
programming language (inheriting from an instance created with a constructor
instead of from the prototype object of that constructor), and so ...
Norris.prototype.kick = function(){
Object.getPrototypeOf(this).kick("Roundhouse");
};
.... I seriously hope that Resig doesn't have a word to say in creating the
next revision of the ECMAScript Specification if the proposed feature is
merely based on this or his other misconceptions.

This example does not make sense, for you can simply omit the definition of
Norris.prototype.kick and the prototype chain would work its way.

Getting the next object in the the prototype chain from a prototype method
is only useful if duplication of code should be prevented. However,
devising a method for that is merely syntactic sugar as the identifier of
the constructor of the prototype is known. Such a feature should then be
inherited from Object.prototype, and not `Object', by a property that has
the DontEnum attribute:

this.super.kick("Roundhouse");

or as a superglobal

super.kick("Roundhouse");

In my libraries, I have the method that sets up the prototype chain add a
`_super' property to the prototype object that refers to the next object in
the prototype chain. (One has to take care, though, that an iterator method
filters it out for for-in iteration.)

`super' is a future reserved word in ECMAScript Ed. 3; it does not make
sense to invent another mechanism instead of defining `super' (including a
more expensive method call) in later revisions of ECMAScript.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Nov 2 '08 #23

P: n/a
On Nov 2, 2:38 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

[snip]
... I seriously hope that Resig doesn't have a word to say in creating the
next revision of the ECMAScript Specification if the proposed feature is
merely based on this or his other misconceptions.
He doesn't participate much on the es-3.1 or es-harmony email lists
and does not appear to be on the formal committee.

[snip]

Peter
Nov 3 '08 #24

P: n/a
On 2 nov, 04:38, Thomas 'PointedEars' Lahn <PointedE...@web.dewrote:
dylan m. austin wrote:
[...]
http://ejohn.org/blog/objectgetprototypeof/
It covers the Object.getPrototypeOf method they've come up with
for ECMAScript 3.1 and shows a basic example of getting super-
functionality with it. I'll reproduce that here:
function Person(){}
Person.prototype.kick = function(type){
* alert(type + " kick!");
}
function Norris(){}
// Inherit properties from Person
Norris.prototype = new Person();

Obviously, as it has been explained numerous times before, that is _not_ the
proper way to emulate class-based inheritance in a prototype-based
programming language (inheriting from an instance created with a constructor
instead of from the prototype object of that constructor), and so ...
I'm glad you mention that. It's a shame the most propagated example of
inheritance in javascript is exactly that.
Norris.prototype.kick = function(){
* Object.getPrototypeOf(this).kick("Roundhouse");
};

... I seriously hope that Resig doesn't have a word to say in creating the
next revision of the ECMAScript Specification if the proposed feature is
merely based on this or his other misconceptions.

This example does not make sense, for you can simply omit the definition of
Norris.prototype.kick and the prototype chain would work its way.
I'm pretty sure homeboy wrote that as an example where you were
supposed to 'fill in the blanks' a bit, as if there were some extra
functionality added in the Norris.prototype.kick method. Though
undoubtedly he should have taken the time to create a more lucid
example.
Getting the next object in the the prototype chain from a prototype method
is only useful if duplication of code should be prevented. *However,
devising a method for that is merely syntactic sugar as the identifier of
the constructor of the prototype is known. *Such a feature should then be
inherited from Object.prototype, and not `Object', by a property that has
the DontEnum attribute:

* this.super.kick("Roundhouse");

or as a superglobal

* super.kick("Roundhouse");

In my libraries, I have the method that sets up the prototype chain add a
`_super' property to the prototype object that refers to the next object in
the prototype chain.
The only thing I meant to point out by mentioning Resig's post was
that there is now a proposed feature in 3.1 that allows direct access
to an object's [[prototype]]. Thus you wouldn't need to be adding your
own _super property to your prototypes. Not to say I prefer the
proposed feature or anything.

Also in future posts all try and avoid mentioning the names of any
pundits as it only creates noise here.
Nov 3 '08 #25

P: n/a
Peter Michaux wrote:
Thomas 'PointedEars' Lahn wrote:
>... I seriously hope that Resig doesn't have a word to say in creating the
next revision of the ECMAScript Specification if the proposed feature is
merely based on this or his other misconceptions.

He doesn't participate much on the es-3.1 or es-harmony email lists
and does not appear to be on the formal committee.
Thanks, that's comforting ;-)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Nov 3 '08 #26

This discussion thread is closed

Replies have been disabled for this discussion.