If you use the prototype for attaching methods then you have one copy of the method shared between all the objects that use it. If you don't use prototype then each object will have its own separate copy of the method.

1. A separate copy for each uses more memory.
2. If you have code to change the method then having one copy is easier to change than having an unknown number of separate copies.

08-11-2013, 08:35 PM

joesimmons

Prototypal inheritance, sir. Research it.

08-12-2013, 05:23 AM

phantom007

Quote:

Originally Posted by felgall

If you use the prototype for attaching methods then you have one copy of the method shared between all the objects that use it. If you don't use prototype then each object will have its own separate copy of the method.

1. A separate copy for each uses more memory.
2. If you have code to change the method then having one copy is easier to change than having an unknown number of separate copies.

Because the shuffle method is added to the Array.prototype that single copy of the code can be run for any array including arrays created by that method. If you did not add it to the ptototype then the shuffle method would need a separate copy for each of the arrays instead of sharing the one copy between all arrays.

Because the shuffle method is added to the Array.prototype that single copy of the code can be run for any array including arrays created by that method. If you did not add it to the ptototype then the shuffle method would need a separate copy for each of the arrays instead of sharing the one copy between all arrays.

Hmm. that does not shuffle the shuffled arrays. Simple test/inspection of results reveals.

you can tack-on prototype methods and properties at any time, but adding own properties would require modifying the constructor code, which might not always be feasible or practical. felgall's array prototype is a good example of this. it's easier to decorate something that already exists and is working, rather than duplicate a bunch of functionality in a "sub class".

08-12-2013, 12:06 PM

007julien

Not to alter the original array, I would prefer, like Philip M, this variant

Ummm...Philip misspoke. Or perhaps his meaning simply wasn't clear (at least to me). That *does* shuffle the arrays, but it shuffles AND REPLACES the given array.

That is, for example, when you do var d = b.shuffle() you end up shuffling b *IN PLACE* and then assigning that shuffled version to d, resulting in two arrays with the same content. (Or, more correctly, two variables referencing the same array object.)

And because of the use of this.splice(), you lose the original array.

Julien's solution fixes that (or changes that, if it was intended behavior).

08-12-2013, 08:28 PM

felgall

Quote:

Originally Posted by Old Pedant

Julien's solution fixes that (or changes that, if it was intended behavior).

So my example turned out better than I thought because it illustrates that to fix a problem such as this one that as prototype was used there is only the one copy of the code that needs to be altered to apply the fix.

08-12-2013, 09:48 PM

Old Pedant

слишком много правды !!

Too much truth!

08-13-2013, 07:38 AM

Philip M

Quote:

Originally Posted by Old Pedant

Ummm...Philip misspoke. Or perhaps his meaning simply wasn't clear (at least to me). That *does* shuffle the arrays, but it shuffles AND REPLACES the given array.

That is, for example, when you do var d = b.shuffle() you end up shuffling b *IN PLACE* and then assigning that shuffled version to d, resulting in two arrays with the same content. (Or, more correctly, two variables referencing the same array object.)

And because of the use of this.splice(), you lose the original array.

Julien's solution fixes that (or changes that, if it was intended behavior).

For the life of me I do not see the use of "two arrays with the same content. (Or, more correctly, two variables referencing the same array object.)".
How can it make sense to lose/replace the original array? That was the point I was trying to make.

FWIIW, I have been involved with Javascript for 15 years and I think that I understand prototypes. But I have never had an occasion to use one or found any situation when one was necessary. I admit that I have never been involved in really large code projects.

08-13-2013, 07:55 AM

felgall

Quote:

Originally Posted by Philip M

But I have never had an occasion to use one or found any situation when one was necessary.

Does that mean that you have never needed to define methods for objects - since the prototype always gets used when adding methods so that the one set of code can be shared?

Presumably you have also never needed to implement classical inheritance in JavaScript since that requires both the prototype and constructor properties in order to do it properly.

There are many other things only possible in JavaScript using prototype - including the many things that can be done in a prototyping language that you can't do in an OO language.