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

What's the difference between someFunc.blah = function(){} and someFunc.prototype.blah = function(){}?

P: n/a
Daz
Hi everyone.

My query is very straight forward (I think).

What's the difference between

someFunc.blah = function(){ ; }

and

someFunc.prototype.blah = function(){ ; }

? Does someFunc.blah call upon someFunc.prototype.blah? Is there any
difference?

Many thanks.

Daz.

Dec 21 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a

Daz wrote:
Hi everyone.

My query is very straight forward (I think).

What's the difference between

someFunc.blah = function(){ ; }

and

someFunc.prototype.blah = function(){ ; }

? Does someFunc.blah call upon someFunc.prototype.blah? Is there any
difference?

Many thanks.

Daz.
Take a look over this:
http://www.javascriptkit.com/javatutors/oopjs.shtml
On page 2 you will find the answer you are looking for.

Dec 21 '06 #2

P: n/a
Daz wrote:

[snip]
What's the difference between

someFunc.blah = function(){ ; }

and

someFunc.prototype.blah = function(){ ; }

? Does someFunc.blah call upon someFunc.prototype.blah?
No.
Is there any difference?
Yes, a very large one.

Properties of a prototype object are only significant when the function
- in this case, someFunc - is used as a constructor function. The
prototype object becomes part of the prototype chain, affecting what
values are obtained when reading a property of the new object.

When reading a property from an object, first the object itself is
checked to determine whether it has a property with that name. If so,
the value of that property is the result. If not, the first object in
the prototype chain is checked in the same way. This repeats until
either the property has been found, or the end of the chain has been
reached, in which case the result is the value, undefined.

This can be demonstrated quite simply.

var object;

function MyObject() {}
MyObject.myProperty = 'value';

object = new MyObject();

At this point, the function MyObject has a property named myProperty,
and an object has been created using that function. The aforementioned
property exists only on the function object -- the constructor function
-- and none of the objects created from it: the expression

typeof object.myProperty

will evaluate to 'undefined', not 'string'.

If, instead, the prototype object is modified:

var object;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

different behaviour is seen. This time around, the constructor function
has no property named myProperty, but the object created using the
constructor does: the expressions

typeof object.myProperty

and

typeof MyObject.myProperty

will evaluate to 'string' and 'undefined', respectively. The value of
the former property is 'foo'.

Finally, it can be observed that adding a property directly to an object
obscures any value that might be obtained from the prototype chain.
Moreover, the prototype property remains unchanged:

var object, anotherObject;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();
anotherObject = new MyObject();

object.myProperty = 'bar';

Both objects have a property named myProperty, but the values differ:
the property of anotherObject obtains its value from the prototype
chain, whilst the property of object does not. The last assignment
statement creates a new property on the object, object, itself. In this
way, properties of a prototype object can be seen as default values for
object properties.
Keep in mind that the prototype chain is an internal property of
objects, and the chain itself cannot be changed once an object has been
created:

var object, anotherObject;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

/* object.myProperty == 'foo' */

MyObject.prototype = {myProperty: 'bar'};

anotherObject = new MyObject();

/* object.myProperty == 'foo'
* anotherObject.myProperty == 'bar'
*/

If changing the value of the prototype property of MyObject had an
effect on existing objects, both objects would have observed a change in
value. As it happens, only new objects are affected.

However, if references to objects in the chain are retained,
modifications to them do have an effect:

var object;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

/* object.myProperty == 'foo' */

MyObject.prototype.myProperty = 'bar';

/* object.myProperty == 'bar' */

Hope that helps,
Mike
Dec 29 '06 #3

P: n/a
Daz

Michael Winter wrote:
Daz wrote:

[snip]
What's the difference between

someFunc.blah = function(){ ; }

and

someFunc.prototype.blah = function(){ ; }

? Does someFunc.blah call upon someFunc.prototype.blah?

No.
Is there any difference?

Yes, a very large one.

Properties of a prototype object are only significant when the function
- in this case, someFunc - is used as a constructor function. The
prototype object becomes part of the prototype chain, affecting what
values are obtained when reading a property of the new object.

When reading a property from an object, first the object itself is
checked to determine whether it has a property with that name. If so,
the value of that property is the result. If not, the first object in
the prototype chain is checked in the same way. This repeats until
either the property has been found, or the end of the chain has been
reached, in which case the result is the value, undefined.

This can be demonstrated quite simply.

var object;

function MyObject() {}
MyObject.myProperty = 'value';

object = new MyObject();

At this point, the function MyObject has a property named myProperty,
and an object has been created using that function. The aforementioned
property exists only on the function object -- the constructor function
-- and none of the objects created from it: the expression

typeof object.myProperty

will evaluate to 'undefined', not 'string'.

If, instead, the prototype object is modified:

var object;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

different behaviour is seen. This time around, the constructor function
has no property named myProperty, but the object created using the
constructor does: the expressions

typeof object.myProperty

and

typeof MyObject.myProperty

will evaluate to 'string' and 'undefined', respectively. The value of
the former property is 'foo'.

Finally, it can be observed that adding a property directly to an object
obscures any value that might be obtained from the prototype chain.
Moreover, the prototype property remains unchanged:

var object, anotherObject;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();
anotherObject = new MyObject();

object.myProperty = 'bar';

Both objects have a property named myProperty, but the values differ:
the property of anotherObject obtains its value from the prototype
chain, whilst the property of object does not. The last assignment
statement creates a new property on the object, object, itself. In this
way, properties of a prototype object can be seen as default values for
object properties.
Keep in mind that the prototype chain is an internal property of
objects, and the chain itself cannot be changed once an object has been
created:

var object, anotherObject;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

/* object.myProperty == 'foo' */

MyObject.prototype = {myProperty: 'bar'};

anotherObject = new MyObject();

/* object.myProperty == 'foo'
* anotherObject.myProperty == 'bar'
*/

If changing the value of the prototype property of MyObject had an
effect on existing objects, both objects would have observed a change in
value. As it happens, only new objects are affected.

However, if references to objects in the chain are retained,
modifications to them do have an effect:

var object;

function MyObject() {}
MyObject.prototype.myProperty = 'foo';

object = new MyObject();

/* object.myProperty == 'foo' */

MyObject.prototype.myProperty = 'bar';

/* object.myProperty == 'bar' */

Hope that helps,
Mike
Thanks a lot for that Mike! It's really helped me out a lot. I also
heard that using prototype is more effective than declaring the
properties/methods inside of the function, as when prototype is used,
each new instance of the object is simply updated with a reference to
the new prototype, rather than having a fresh instance of each object,
inside of the newly created objects (if that makes sense).

Basically, using prototypes can save RAM usage, and hopefully speed the
objects up marginally.

Very useful stuff.

Thanks again. :)

Daz.

Dec 29 '06 #4

P: n/a
Daz wrote:

[snip]
Thanks a lot for that Mike! It's really helped me out a lot.
My apologies that I took so long to reply. It's been on my to-do list
for a while.
I also heard that using prototype is more effective than declaring the
properties/methods inside of the function, as when prototype is used,
each new instance of the object is simply updated with a reference to
the new prototype, rather than having a fresh instance of each object,
inside of the newly created objects (if that makes sense).
You're referring to

function MyObject() {
this.method = function () {
/* ... */
};
}

versus

function MyObject() {}
MyObject.prototype.method = function () {
/* ... */
};

right?

When a function expression is evaluated, a new function object is
created. In the first of the two snippets above, the function expression
inside the body of MyObject will be evaluated every time MyObject is
invoked -- every time a new object is created from MyObject. In the
second, the function expression is only evaluated once.
Basically, using prototypes can save RAM usage, and hopefully speed the
objects up marginally.
Memory, certainly; construction time, as well. Obtaining the value of
the property will take slightly longer though as it becomes necessary to
search the prototype chain rather than finding the property immediately
on the object itself. As trade-offs go, it's not a bad one.

There are, of course, circumstances where the first approach is best:
when a closure is needed for some reason. This is typically when using
"private" members.
Very useful stuff.

Thanks again. :)
You're welcome. :-)

Mike
Dec 29 '06 #5

P: n/a
Daz

Michael Winter wrote:
My apologies that I took so long to reply. It's been on my to-do list
for a while.
No problem. I am just greatful for your help.
I also heard that using prototype is more effective than declaring the
properties/methods inside of the function, as when prototype is used,
each new instance of the object is simply updated with a reference to
the new prototype, rather than having a fresh instance of each object,
inside of the newly created objects (if that makes sense).

You're referring to

function MyObject() {
this.method = function () {
/* ... */
};
}

versus

function MyObject() {}
MyObject.prototype.method = function () {
/* ... */
};

right?
Yes, indeed.
When a function expression is evaluated, a new function object is
created. In the first of the two snippets above, the function expression
inside the body of MyObject will be evaluated every time MyObject is
invoked -- every time a new object is created from MyObject. In the
second, the function expression is only evaluated once.
Basically, using prototypes can save RAM usage, and hopefully speed the
objects up marginally.

Memory, certainly; construction time, as well. Obtaining the value of
the property will take slightly longer though as it becomes necessary to
search the prototype chain rather than finding the property immediately
on the object itself. As trade-offs go, it's not a bad one.
Oh I see. So I guess it depends on the application of the code as to
which one would be best to use, as always.
There are, of course, circumstances where the first approach is best:
when a closure is needed for some reason. This is typically when using
"private" members.
Precisely. Thank you so much for your input again. If I can remember
even 50% of it, then I am off to a good start. Some day I will become a
JavaScript guru. I just hope that day comes before I die. Hehe.

I would like to wish you a happy new year, in advance.

Daz.

Dec 29 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.