Crockford's 'The Good Parts' : a short review

[David Mark]

I do not know what "base instance" is supposed to mean.  However, Google
knows I thought so some time ago, and it turned out that the ECMAScript
Specification disagrees with me.  "Instance" might not be the best termas
it is confusing with respect to class-based OOP, but it is a term used
frequently in the Specification.  So it is only only reasonable to adopt it
where it fits, as well as Specification-based terms like "global object",
"scope chain", and "activation object" have been adopted in discussions here.

[snip]

Fair enough. Consider the right-hand an "instance."

X.prototype = new Y();

We know that's not right by itself. I think what confuses people is
that the same line can appear in the right answer that clones an
existing prototype object, rather than setting the new prototype to a
"base instance", which would include properties assigned in the "base
constructor."

 

[John G Harris]

David Mark wrote:


I do not know what "base instance" is supposed to mean. However, Google
knows I thought so some time ago, and it turned out that the ECMAScript
Specification disagrees with me. "Instance" might not be the best term as
it is confusing with respect to class-based OOP, but it is a term used
frequently in the Specification. So it is only only reasonable to adopt it
where it fits, as well as Specification-based terms like "global object",
"scope chain", and "activation object" have been adopted in discussions here.

As discussed before, the proposed concise surrogate term for "Foo instance",
"Foo object", is only a little bit less confusing as it can still refer both
to an object constructed with the object referred to by `Foo', and to the
constructor itself. With respect to DOM APIs and other multi-level
inheritance hierarchies, there are even three meanings attached to it, the
third being "Foo.prototype is in the prototype chain of said object".

Instance is too useful a word to throw away. Take any lump of code that
creates objects that have a lot in common with each other. It's
reasonable to say that each object is an instance of the objects that
can be created by that lump of code. It's in javascript's nature for
there to be several ways to organise such lumps of code, so instance
shouldn't be restricted to one way of creating objects, unlike in
languages such as Java and C++.

As for 'base instance', suppose one lump of code creates objects that
have all the methods and data properties of objects produced by another
lump of code, plus some more. If you're thinking OO then obviously the
first lot of objects inherits a specification from the second lot of
objects, and the first lot are called derived, and the second lot are
called base. Obviously, an object belonging to the second lot is a base
instance.

It's not a good idea to use a base instance as the prototype object for
the derived instances. Instead, a separate lump of code should be used
to create the prototype. This lump of code presumably creates only one
object, but it is still reasonable to call the object an instance (of
the separate lump of code).

John