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

prototypes and references

P: n/a
Hi,

A discussion on the YUI page is depending on some speculation and I
know someone here knows the truth. Below is the relevant section. If
you can clarify this confusion I would greatly appreciate it.

Thanks,
Peter
One person wrote:
I'm not entirely sure how browsers handle prototypes, but I strongly
suspect that any item that makes use of a prototype contains
references (function pointers) to the prototype code, and that
overloading is performed simply by overwriting these references.
I responded:

I don't think this is the way it works. I think that if the object
doesn't contain the method then the next place the compiler looks is
in the prototype for the objects class. If it works like you suggested
then if you create an inheritance chain the object would need method
references for all methods in the inheritance chain. I don't think the
guys writing compilers want to work that hard.

Jul 7 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hi Peter,

A reference is kept to the prototype. The actual function in the
prototype is not overwritten. When invoking a function it first looks at
the actual object. If that object does not contain the function or
variable, it looks at the prototype's functions and variables (and the
prototype's prototype and so on).

Vincent

pe**********@gmail.com schreef:
Hi,

A discussion on the YUI page is depending on some speculation and I
know someone here knows the truth. Below is the relevant section. If
you can clarify this confusion I would greatly appreciate it.

Thanks,
Peter
One person wrote:
> I'm not entirely sure how browsers handle prototypes, but I strongly
suspect that any item that makes use of a prototype contains
references (function pointers) to the prototype code, and that
overloading is performed simply by overwriting these references.

I responded:

I don't think this is the way it works. I think that if the object
doesn't contain the method then the next place the compiler looks is
in the prototype for the objects class. If it works like you suggested
then if you create an inheritance chain the object would need method
references for all methods in the inheritance chain. I don't think the
guys writing compilers want to work that hard.
Jul 7 '06 #2

P: n/a
Vincent van Beveren wrote:
>
A reference is kept to the prototype. The actual function in the
prototype is not overwritten. When invoking a function it first looks at
the actual object. If that object does not contain the function or
variable, it looks at the prototype's functions and variables (and the
prototype's prototype and so on).
This is what I thought but I wanted some extra confimation. I reread in
Flanagan's JavaScript book (4th ed. p 121) and it confirms this also.

Thanks,
Peter

Jul 7 '06 #3

P: n/a
pe**********@gmail.com wrote:
A discussion on the YUI page is depending on some speculation
and I know someone here knows the truth. Below is the relevant
section. If you can clarify this confusion I would greatly
appreciate it.
<snip>
One person wrote:
> I'm not entirely sure how browsers handle prototypes,
Which is a bad sign as it doesn't take into account that javascript is
used to script more than just browsers and in order to be useful needs
to behave the same in non-browsers as it does in browsers.
> but I strongly suspect that any item that makes use of
a prototype contains references (function pointers) to
the prototype code, and that overloading is performed
simply by overwriting these references.
If that were true you would lose the ability to delete the properties of
an object and by doing so revert to the values of its prototype.
I responded:

I don't think this is the way it works. I think that if
the object doesn't contain the method then the next place
the compiler looks is in the prototype for the objects class.
<snip>

It is misleading to be talking of classes when directly discussing
javascript's actual behaviour, as it has no classes (or it has just one
class, which is much the same thing). The terminology from class-based
languages can be a useful shorthand when implementing concepts that
parallel those of class-based languages, but they tend to get in the way
when discussing the actual mechanism of the prototype-based inheritance
that javascript employs.

The definitive answer is, of course, in the language's specification:-

ECMA 262, 3rd Ed.

Section 13.2.2 the [[Construct]] method of functions (how the
[[Prototype]] is assigned).
Section 8.7.1 the internal GetValue function.
Section 8.6.2.1 the [[Get]] method of native ECMAScript objects.

- and other places. Speculation can be unnecessary when you have
specification.

Richard.
Jul 7 '06 #4

P: n/a
Richard Cornford wrote:
>
It is misleading to be talking of classes when directly discussing
javascript's actual behaviour, as it has no classes (or it has just one
class, which is much the same thing). The terminology from class-based
languages can be a useful shorthand when implementing concepts that
parallel those of class-based languages, but they tend to get in the way
when discussing the actual mechanism of the prototype-based inheritance
that javascript employs.
Very good point.
The definitive answer is, of course, in the language's specification:-

ECMA 262, 3rd Ed.

Section 13.2.2 the [[Construct]] method of functions (how the
[[Prototype]] is assigned).
Section 8.7.1 the internal GetValue function.
Section 8.6.2.1 the [[Get]] method of native ECMAScript objects.
Thanks for these pointers.

Peter

Jul 8 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.