Prototype Convention?

[Martin Rinehart]

Is there a convention for setting up a prototype?

You could write:

Foo.prototype = {};
Foo.prototype.toString = function ...
Foo.prototype.other = ...

or you could write:

Foo.prototype = {
toString: function ...,
other:...
};

 

[John G Harris]

Is there a convention for setting up a prototype?

You could write:

Foo.prototype = {};
Foo.prototype.toString = function ...
Foo.prototype.other = ...

or you could write:

Foo.prototype = {
toString: function ...,
other:...
};

A third way is to treat it as an object that needs to be constructed
just like any other object :
Foo.prototype = new protoFoo();
Now the code to make the prototype is neatly packaged inside the
protoFoo code, and your prototype object can have any prototype you
choose.

John

 

[John G Harris]

In both cases the prototype object attached to Foo is an ordinary
object. But it might be 'an instance of another class'.

You can't get that with the second approach (an object literal) but you
can with the first:
Foo.prototype = new Bar();

But note that Foo.prototype now holds a Bar object's data. That data is
irrelevant at best, and thoroughly confusing at worst.

John

 

[Lasse Reichstein Nielsen]

Is there a convention for setting up a prototype?

You could write:

Foo.prototype = {};
Foo.prototype.toString = function ...
Foo.prototype.other = ...

or you could write:

Foo.prototype = {
toString: function ...,
other:...
};

The former has the advantage of always working.
If an object has already been created from the Foo function, changing
the prototype property will not affect old objects, but extending the
existing prototype object will add the functions to the old objects
as well.
The "constructor" property on the original Foo.prototype needs to be
copied too, if you replace the Foo.prototype object. Who knows which
frameworks might expect it to be there.
Likewise for properties that someone else has already extended the
original prototype with.

All "problems" that might not apply in any particular case, but you
have to ensure that (e.g., by only changing the prototype object
immediately after creating the function, and remember to set the
"constructor" property).

/L

 

[Martin Rinehart]

But note that Foo.prototype now holds a Bar object's data. That data is
irrelevant at best, and thoroughly confusing at worst.

Unless foo is intended to extend bar.

 

[Martin Rinehart]

This is nice. I like the consistency - "constructed just like any other
object".

To expand, so you write
===
var protoFoo = function(){

this.toString = function(){
// code
};
}

protoFoo.prototype = new Object(); // Or whatever.
===

Of course, once you've done
Foo.prototype = new protoFoo();
you can if you wish discard protoFoo. If you do, then protoFoo is what
I'd like to call a "use once object initialiser".

 

[Thomas 'PointedEars' Lahn]

Is there a convention for setting up a prototype?

Yes, there is. This is a *news*group; please search before you post.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Good point. You really need an uninitialized 'instance of Bar', which
you can get (I saw this idea in Cockcroft's Good Parts book) using:
var F = function(){};
F.prototype = Bar.prototype;
Foo.prototype = new F(); // An 'uninitialised instance of Bar'.

Perhaps I should have mentioned something like this when comparing the
two approaches put forward by the original poster.

This is a *news*group. Google for clone() and inheritFrom().


PointedEars

 

[Thomas 'PointedEars' Lahn]

The former has the advantage of always working.

There are no differences in semantics or compatibility between the two
approaches *at all*.


PointedEars

 

[Lasse Reichstein Nielsen]

There are no differences in semantics or compatibility between the two
approaches *at all*.

Except the ones I *actually listed*?

All it takes is for someone to be able to change the original
prototype, or get a reference to it, before you get to do anything,
then there is a lot of difference between updating the existing one or
replacing it.

If that doesn't apply, great: Use whatever feels best.


/L

 

[Joost Diepenmaat]

Except the ones I *actually listed*?

All it takes is for someone to be able to change the original
prototype, or get a reference to it, before you get to do anything,
then there is a lot of difference between updating the existing one or
replacing it.

If that doesn't apply, great: Use whatever feels best.

Thomas is right. You seem to have missed that both posted variants
assign to Foo.prototype

 

[John G Harris]

This is a *news*group.

The word "news" was chosen unwisely when Usenet was invented, as you
very well know.

Google for clone() and inheritFrom().

The identifier "clone" has been used by thousands of programmers. Which
crappy library/book are you referring to ?

John

 

[John G Harris]

Unless foo is intended to extend bar.

No, the foo prototype is intended to extend the bar *prototype*.

Usually, prototype objects hold read-only properties, unless you're
doing something really tricky.

Usually, ordinary objects hold read-write properties, unless you're
convinced you won't make the mistake of writing to a property that is
designed to be read-only.

Thus, usually, prototype objects hold function objects (the methods) and
ordinary objects hold instance data (strings, numbers, simple objects,
etc).

John

 

[David Mark]

Thomas is right. You seem to have missed that both posted variants
assign to Foo.prototype

No, the first example augmented the existing prototype. The second
replaced it wholesale.

[snip]

 

[Joost Diepenmaat]

No, the first example augmented the existing prototype. The second
replaced it wholesale.

Quoted from the post:

Foo.prototype = {};
Foo.prototype.toString = function ...
Foo.prototype.other = ...

or you could write:

Foo.prototype = {
toString: function ...,
other:...
};

 

[Thomas 'PointedEars' Lahn]

No, the first example augmented the existing prototype. The second
replaced it wholesale.

You are mistaken. It is easy to miss, but the empty Object literal (`{}')
creates a *new* Object object and assigns a reference to it to Foo.prototype
as well as the non-empty one (`{toString: ...}') does.

If that first assignment was omitted from the first example, then you and
Lasse were right.

However, the pattern

Foo.prototype.toString = function ...
Foo.prototype.other = ...
...

as compared to

Foo.prototype = {
...
};

is also less efficient (because of repeated lookups) and slightly harder to
maintain (because of repeated identifiers). So, when keeping the existing
prototype object is desired, I use(d) a method to augment the prototype
object (or just any object) instead (see JSXbject.js:addProperties() [1],
comments welcome); other developers have devised their own methods to do
about the same, e.g. Douglas Crockford introduces the Function.method()
method in his inheritance and code reuse examples [2].


PointedEars
___________
[1] <http://pointedears.de/scripts/object.js>
[2] <http://javascript.crockford.com/inheritance.html>

 

[David Mark]

You are mistaken.  It is easy to miss, but the empty Object literal (`{}')
creates a *new* Object object and assigns a reference to it to Foo.prototype
as well as the non-empty one (`{toString: ...}') does.

Yes. Somehow I missed that first line.

If that first assignment was omitted from the first example, then you and
Lasse were right.

However, the pattern

  Foo.prototype.toString = function ...
  Foo.prototype.other = ...
  ...

as compared to

  Foo.prototype = {
    ...
  };

is also less efficient (because of repeated lookups) and slightly harder to
maintain (because of repeated identifiers).  So, when keeping the existing

Yes.

[snip]

 

[Thomas 'PointedEars' Lahn]

[...] So, when keeping the existing prototype object is desired, I use(d)
a method to augment the prototype object (or just any object) instead
(see JSXbject.js:addProperties() [1], comments welcome); other
developers have devised their own methods to do about the same, e.g.
Douglas Crockford introduces the Function.method() method in his ^^^^^^^^^^^^^^^^^^^^^^^^
inheritance and code reuse examples [2].

Actually, that's the Function.prototype.swiss() method there. The way it
was augmented had me confused shortly

----- bite here -----
Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

// [...]

Function.method('swiss', function (parent) {
for (var i = 1; i < arguments.length; i += 1) {
var name = arguments;
this.prototype[name] = parent.prototype[name];
}
return this;
});
----- bite here -----

[...]
[1] <http://pointedears.de/scripts/object.js>
[2] <http://javascript.crockford.com/inheritance.html>

PointedEars

 

[Lasse Reichstein Nielsen]

Thomas is right. You seem to have missed that both posted variants
assign to Foo.prototype

Argh. Correct, my bad.

/L

 

[dhtml]

Argh. Correct, my bad.

Each user-defined function gets a prototype property for free, so you
don't need to define it.

function Wibbler() { }

Wibbler.prototype.getCalfMuscle = function() {
return this.gastrocnemius || this.soleus || this.tibia;
};

alert(new Wibbler().constructor); // Wibbler.

The new Wibbler's constructor property {DontEnum} exists on the
Wibbler's prototype property, as Wibbler.prototype.constructor.

This is explained in the section on creating Function objects:
http://bclary.com/2004/11/07/#a-13.2

An interesting side effect is that the common practice of replacing the
Function object's prototype property will result in object's getting the
constructor property from the new object. This can be shown in an example:

function Wibbler() { }
Wibbler.prototype = {};
alert(new Wibbler().constructor); // Object.

The new Wibbler's constructor is not found in wibbler.prototype
directly, but in the [[Prototype]] object for Wibbler.prototype.

So we can replace it:-

function Wibbler() { }
Wibbler.prototype = {};
Wibbler.prototype.constructor = Wibbler;
alert(new Wibbler().constructor); // Wibbler.

- but now it is enumerable -

var w = new Wibbler;
for(var p in w)
alert(p);

elerts "constructor"

Garrett