Q: terminology function, object

[Richard A. DeVenezia]

First: Many thanks to all the superb help. This list is a real gem.

I would like to be precise in some messages I alert()

Suppose I have this

function funData () {
this.balloons = 'yes'
}

function funRender ( funThing ) {
var fun
if ( typeof (funThing) == 'function' ) {
fun = new funThing
}
else
if ( typeof (funThing) == 'object' ) {
fun = funThing
}
else {
alert ( '1. when you invoke funRender pass it your fun function or fun
object' )
// or
//alert ( '2. when you invoke funRender pass it your fun class or fun
instance' )
return false
}

if (fun.balloons && fun.balloons == 'yes') {
alert ('You got it, balloons!')
}

return true
}

funRender ( funData )
funRender ( new funData )
funRender ( { balloons: 'yes' } )
funRender ( 0 ) // alert
funRender ( 'balloons' ) // alert


alert 1. I think pure JS programmers would grok this best
alert 2. I think someone coming into JS from other languages might grok this
best.

Which has your vote ?

Do I have to unthink this " A function is just an object which has typeof()
= 'function' and can be instantiated" ?

 

[Lasse Reichstein Nielsen]

alert ( '1. when you invoke funRender pass it your fun function or fun
object' ) ....
//alert ( '2. when you invoke funRender pass it your fun class or fun ....
alert 1. I think pure JS programmers would grok this best
Definitly

alert 2. I think someone coming into JS from other languages might grok this
best.

I came from other languages, but quickly learned that there are no
classes in Javascript. It confuzes me, as I don't know what is meant
by "class". It is simply not in my Javascript terminology.

Which has your vote ?

I would go for:
when you invoke funRender pass it your fun constructor function or fun object

Do I have to unthink this " A function is just an object which has typeof()
= 'function' and can be instantiated" ?

There are several different definitions:

A function is just an object that implements the [[Call]] method internally.

A function is just an object that can be called

A function is an object that has a typeof of "function"

I wouldn't define functions by their ability to be instantiated. I
would rather define instantiation as something you can do to a
function. Most functions are never used as constructors.

/L

 

[Richard A. DeVenezia]

....

Do I have to unthink this " A function is just an object which has typeof()
= 'function' and can be instantiated" ?

There are several different definitions:

A function is just an object that implements the [[Call]] method internally.

A function is just an object that can be called

A function is an object that has a typeof of "function"

I wouldn't define functions by their ability to be instantiated. I
would rather define instantiation as something you can do to a
function. Most functions are never used as constructors.

/L

JavaScript: It's so simple it's complex.

I am trying to get my mindset around all these swirly new ways to think, and
getting there slowly.

I just observed this

var gThis;

function foo (x) { this.x = x; gThis=this; return this }
f1 = foo(1); alert (f1 == gThis)
f2 = new foo(2); alert (f2 == gThis)

function bar (x) { gThis=this; this.x =x }
b1 = bar(1); alert (b1==undefined)
b2 = new bar(2); alert (b2==gThis)

all alerts are true.

Is obtaining an object by invoking a function that returns this , always
the same as using the new operator to obtain an object ?
( The objects would be different instances of course ( unless constuctor
enforces singletoness ))

and spiraling off to non-constructor methods
function x2 (x) { return x**2 }
a = x2(3)
b = x2(4)
Is speculation that x2 is anonymously instantiated , invoked and destroyed
for each invocation of x2 ?
Or is x2 parsed and compiled down to some 'ready-to-go' state which is used
over and over at each invocation of x2 ?
Leading to more speculation that ready-state is compiled to at first
invocation after each new definition of x2.

G'nite before I meander into philosophical discourse on ill reasoned
attempts to construct incomplete analogies to incompatible ideas that build
abstract constructs masking complete understanding.

 

[Lasse Reichstein Nielsen]

var gThis;

function foo (x) { this.x = x; gThis=this; return this }
f1 = foo(1); alert (f1 == gThis)

Try adding:
alert(f1 == window);
You will see that it is also true.
When a function is called directly, and not as a member of an object,
it's "this" keyword refers to the global object, the one that the
global variable "window" refers to.

f2 = new foo(2); alert (f2 == gThis)

This gives a completely new object.

function bar (x) { gThis=this; this.x =x }
b1 = bar(1); alert (b1==undefined)

Yes, a function call to a function with no return value, gives
undefined.

b2 = new bar(2); alert (b2==gThis)

but using "new" on a function without a return value gives the
new object.

all alerts are true.

Is obtaining an object by invoking a function that returns this , always
the same as using the new operator to obtain an object ?

No. You only create new objects by using the "new" operator. Just
calling a function doesn't create a new object (unless the function itself
creates objects).

( The objects would be different instances of course ( unless constuctor
enforces singletoness ))

A constructor functiont that creates a singleton, is using the fact that
using the new operator on a function that returns an object, gives the
returned object, even if different from the new object.

and spiraling off to non-constructor methods
function x2 (x) { return x**2 }
a = x2(3)
b = x2(4)
Is speculation that x2 is anonymously instantiated , invoked and destroyed
for each invocation of x2 ?

It isn't. The function declaration creates a property in the global object.
The value of that property is a function object. That function object stays
there.

function foo() {return arguments.callee;} // return the function itself
var a = foo();
var b = foo();
alert(a == b && a == foo);

Or is x2 parsed and compiled down to some 'ready-to-go' state which is used
over and over at each invocation of x2 ?

It is. It is a function declaration.

If you have a function expression inside a loop, it can give different
function objects each time it is executed.

Leading to more speculation that ready-state is compiled to at first
invocation after each new definition of x2.

Didn't catch that one.

G'nite before I meander into philosophical discourse on ill reasoned
attempts to construct incomplete analogies to incompatible ideas that build
abstract constructs masking complete understanding.

'nite

/L

 

[Code Ronin]

JavaScript: It's so simple it's complex.

It is as complex as you want it to be.

var gThis;

function foo (x) { this.x = x; gThis=this; return this }
f1 = foo(1); alert (f1 == gThis)

Let's take just this part. You create the global properties gThis,
foo, and f1. All variables outside of functions, functions, and
variables you forget to declare with var inside of functions end up as
properties of a "global object". When you are running code at the
top-level (outside of a function), "this" is set to that global
object.

So, you set the global variable f1 to the results of foo(1). When you
call a function, "this" is set to the object that the function is
attached to. (Exception: you can change "this" using the call or apply
methods.) In this case, the function foo is attached to the global
object.

this.x = x;

As "this" is the global object, you just created a global variable x.
To prove: add the line "alert ( x );" after the line "alert (f1 ==
gThis);".

As "this" is the global object, your second line sets gThis to the
global object. To prove: add the line "alert ( gThis.x );".

Then you return "this", which is assigned to the global variable f1.
So, f1 now points to the global object. To prove: add the line "alert
( f1.x );". This is why gThis == f1, they are both pointing to the
global object.

f2 = new foo(2); alert (f2 == gThis)

function bar (x) { gThis=this; this.x =x }
b1 = bar(1); alert (b1==undefined)

As the bar function no longer returns _any_ value, b1 should be
undefined (which it is, as your alert contends). Actually, a better
way to say it is that all functions return "undefined" implicitly
(exception: when using new, see below). It returns something else only
when you explicitly use the return statement.

b2 = new bar(2); alert (b2==gThis)

When you use "new", JavaScript does a lot behind the scenes. First it
instantiates a blank object (every object inherits from Object), sets
the prototype to the function (in this case bar), sets "this" to the
newly created object, then executes bar.

So now, when "gThis = this;" executes, gThis is no longer pointing to
the global object, but the new object. The interesting side effect
here is that because you reset gThis _before_ the "this.x = x;"
statement, gThis does not have an x property. Proof:
"alert(gThis.hasOwnProperty("x"));" returns false even though it says
b2 == gThis.

Note however that you have no return in bar(), but b2 is not
undefined. That is because of the exception I indicated earlier. When
using new, the function acts as a function constructor and thus the
function has an implicit "return this;" rather than returning
undefined.

By the way, you can return something other than "this" in a
constructor function; this is how you create singletons in JavaScript.

and spiraling off to non-constructor methods
function x2 (x) { return x**2 }
a = x2(3)
b = x2(4)
Is speculation that x2 is anonymously instantiated , invoked and destroyed
for each invocation of x2 ?

No. x2() is a property of the global object, which has a function
object attached as its value. Proof: "alert ( typeof ( this.x2 ));
alert ( this.x2.toString ( ));".

Or is x2 parsed and compiled down to some 'ready-to-go' state which is used
over and over at each invocation of x2 ?

Kind of. It is parsed looking for syntactic errors, but objects are
instantiated only "one level down", meaning when you are in global
code, only the top-level (global) functions are instantiated as
objects, but nested functions are not instantiated until you are
within the outer function.

function snafu ( ) {
function fubar ( ) { }
snafu.fubar = fubar;
}
alert ( snafu.hasOwnProperty ( "fubar" )); // false
snafu ();
alert ( snafu.hasOwnProperty ( "fubar" )); // true

Hope that helps.

 

[Richard A. DeVenezia]

"Richard A. DeVenezia" <[email protected]> wrote in message

Hope that helps.

Very much helps.

You and Lasse mention

this is how you create singletons in JavaScript.

Is this stab in the dark close (admitted an external agency could break the
singleton by messing with the .singleton property) ?

function foo () {
if (foo.singleton != undefined)
return foo.singleton

if (this == window)
return new foo()

...

foo.singleton = this
}

 

[Lasse Reichstein Nielsen]

Is this stab in the dark close (admitted an external agency could break the
singleton by messing with the .singleton property) ?

function foo () { ....
foo.singleton = this
}

Yes, that would work.
To avoid other people messing with the singleton, you can make it a
private variable:

var foo = function(){
var singleton;
return function foo(){
if (singleton != undefined) {
return singleton;
}
if (this == window) {
return new foo();
}
//...
singleton = this;
}
}();

/L

 

[Code Ronin]

You and Lasse mention

Is this stab in the dark close (admitted an external agency could break the
singleton by messing with the .singleton property) ?

function foo () {
if (foo.singleton != undefined)
return foo.singleton

if (this == window)
return new foo()

...

foo.singleton = this
}

Here is how I usually do a singleton:

function Singleton ( ) {
if ( Singleton.instance == null ) {
this.x = 1;
this.y = 2;
Singleton.instance = this;
}
return Singleton.instance;
}
Singleton.instance = null;
Singleton.getInstance = function ( ) { return new Singleton ( ); };

This allows the client to use either "new Singleton ( )" or
"Singleton.getInstance ( )". As Lasse pointed out, unless the variable
is private to a function (with var), it is exposed to other people.
This is probably the single most common complaint from OO purists
about scripting languages like JavaScript. Doing it straight-forward
usually results in "public exposure", but:

1. I do not work with a team of developers when doing JavaScript.
2. All libraries I create have been to speed my own coding.
3. I usually find that documenting the public "interface" well will
usually solve others from poking around and using what you did not
intend.

I once asked Douglas Crockford how he handled all properties being
accessible in the JavaScript library he worked on and he indicated
that he had a programmer that would violate the "public interface"
every so often. He pretty much would add what was necessary to the
interface, clean up the violations, communicate the changes, and move
on. I agree with that theory.

For the most part, JavaScript is not a real memory hog, but when you
start using closures heavily in order to make variables private, you
add to the memory used tremendously and you slow down the code. If you
are talking a dozen or so objects -- no big deal. But if you are
talking hundreds of objects and slower (i.e. non-developer) machines,
you could have a problem.

By the way, if you have not already gone there, see
http://www.crockford.com/javascript for a series of JavaScript
articles on bending JavaScript to your will.

 

[Richard Cornford]

For the most part, JavaScript is not a real memory hog, but
when you start using closures heavily in order to make
variables private, you add to the memory used tremendously
and you slow down the code. If you are talking a dozen or
so objects -- no big deal. But if you are talking hundreds of
objects and slower (i.e. non-developer) machines,
you could have a problem.

I would agree that there is potential to add to the memory use
tremendously when using closures, inner functions and "private" members.
I am, for example, rather alarmed by the code on <URL:
http://www.u.arizona.edu/~jscully/javafication.html > "Javafied
Javascript" and its relentless use of inner functions, one copy of each
for each and every method of each object instantiated (though I have
seen authors do just that with no intention of making an members
private, just because they knew no better).

But it doesn't have to be that bad, choosing the right members to be
private and the right (and minimum number of) methods to be privileged
and private, along with private static functions (for which only one
function object needs to exist) and workable division of public and
private can be achieved with a reasonable memory overhead.

Execution speed, on the other hand, can go both ways. It must take
longer to instantiate the objects, just because of the additional
function objects that need to be created. But I recently did an
experiment to test the speed of property accessor resolution, comparing
object public properties accessed with the - this - keyword against the
resolution of identifiers referring to local variables of outer
functions (and nested outer functions). I wanted to confirm to myself
that following Douglas Crockford's private member pattern wasn't
imposing an execution speed penalty that could be avoided with more
traditional object definitions.

Fortunately the results indicated that the outer function local
variables were resolved faster than public object properties. So if an
object is to be instantiated once and then used extensively (especially
when its performance in operation is significant) the speed advantages
might swing to the closure/inner function code (and be worth the memory
trade off).

Richard.

 

[Richard A. DeVenezia]

In a seperate thread Richard Conford mentions

Douglas Crockford's private member pattern

http://www.crockford.com/javascript/ seems to be closed.
Could you explain it ?

 

[Lasse Reichstein Nielsen]

http://www.crockford.com/javascript/ seems to be closed.
Could you explain it ?

I believe the link should have been
<URL:http://www.crockford.com/#javascript>

/L

 

[Evertjan.]

Richard A. DeVenezia wrote on 07 sep 2003 in comp.lang.javascript:

In a seperate thread Richard Conford mentions


http://www.crockford.com/javascript/ seems to be closed.

No, it is open.

Could you explain it ?

typo ?

 

[Code Ronin]

I am, for example, rather alarmed by the code on <URL:
http://www.u.arizona.edu/~jscully/javafication.html > "Javafied
Javascript" and its relentless use of inner functions, one copy of each
for each and every method of each object instantiated (though I have
seen authors do just that with no intention of making an members
private, just because they knew no better).

Actually, what I am most astonished at is that he read Douglas'
website and still he wants to Javafy JavaScript.

Again, I do not have the incentive to need to privatize my variables
nor the desire to convince the OO purists that what I do is not "bad
OOP" because it does not implement data hiding. So I use prototype to
reduce the number of function objects and the Object Augmentation
pattern to add common functionality to objects that are otherwise
unrelated.

function Foo ( ) {
augmentColor ( this, Foo.prototype, "red" );
// ...
}

function Bar ( ) {
augmentColor ( this, Bar.prototype, "blue" );
// ...
}

function augmentColor ( instance, proto, value ) {
instance.color = value;
if ( ! proto.hasOwnProperty ( "getColor" )) {
proto.getColor = function ( ) { return this.color; };
proto.setColor = function ( val ) { this.color = val; };
}
}

This is my typical implementation now. The idea is simple: reduce the
amount of typing. IMO, it is better than the old:

Foo.prototype.getColor = function ( )...
Foo.prototype.setColor = function ( val )...
Bar.prototype.getColor = function ( )...
Bar.prototype.setColor = function ( val )...

I just do not like all of that top-level code not being stuck in a
function, I guess.

But it doesn't have to be that bad, choosing the right members to be
private and the right (and minimum number of) methods to be privileged
and private, along with private static functions (for which only one
function object needs to exist) and workable division of public and
private can be achieved with a reasonable memory overhead.

But, do you find that you end up mixing styles? I tried that and I
found that the code became less clear (and thus harder to go back to
after a length of time) as not every object was necessarily written in
the same style.

Every programmer has their own style and goals, of course. I guess of
all the "-bilities" my emphasis is on "maintainability". (That is not
to imply that the above style is less maintainable, only that it is
for me as my way of mixing and matching leads to less code
consistency.)

Execution speed, on the other hand, can go both ways. It must take
longer to instantiate the objects, just because of the additional
function objects that need to be created.

I did a number of tests on different styles ("classes", augmentation,
hiding with closures, etc.) and object creation is significant. Then,
I remembered what I had to go through in order to actually time the
results -- 10,000 instances from the same constructor, I think. Not
your typical JavaScript program, I think.

Fortunately the results indicated that the outer function local
variables were resolved faster than public object properties. So if an
object is to be instantiated once and then used extensively (especially
when its performance in operation is significant) the speed advantages
might swing to the closure/inner function code (and be worth the memory
trade off).

How many iterations did you have to do in order to get a timeable
result? (Just curious, not trying to be cheeky.)

 

[Richard Cornford]

Actually, what I am most astonished at is that he read
Douglas' website and still he wants to Javafy JavaScript.

Yes, I didn't entirely see the point. I can understand the desire to
wrap all the code that defines an object into one block structure,
paralleling the class definition in Java and making each "class"
distinct in the source code, but there are ways of doing that without
needing all the function objects that result from that approach.

Again, I do not have the incentive to need to privatize my
variables nor the desire to convince the OO purists that
what I do is not "bad OOP" because it does not implement
data hiding.

I can't argue with that. Web pages (even entire sites) are just not that
complex. Data hiding is important in large systems where accidental
interactions can have undesirable consequences but that is not really
relevant to browser scripting. Still, it is nice to know that it can be
done.

So I use prototype to reduce the number of
function objects and the Object Augmentation pattern
to add common functionality to objects that are otherwise
unrelated.

function Foo ( ) {
augmentColor ( this, Foo.prototype, "red" );
// ...
}

function Bar ( ) {
augmentColor ( this, Bar.prototype, "blue" );
// ...
}

function augmentColor ( instance, proto, value ) {
instance.color = value;
if ( ! proto.hasOwnProperty ( "getColor" )) {
proto.getColor = function ( ) { return this.color; };
proto.setColor = function ( val ) { this.color = val; };
}
}

Some observations. The first invocation of the - augmaneColor - function
is going to form a closure that will contain a reference to the -
instance - object. Wouldn't that mean that the first object instance
cannot be garbage collected until the prototype (and, by implication,
the constructor function) is garbage collected, normally when the page
is unloaded?

You are concerned with the number of function objects created but are
still producing a separate - getColor - and - setColor - function for
each constructor that calls this method, though they are essentially the
same functions.

var augmentColor = (function(){
function getColor(){ return this.color; }
function setcolor(){ this.color = val; }
return (function(instance, proto, value){
instance.color = value;
if(!proto.hasOwnProperty("getColor")){
proto.getColor = getColor;
proto.setColor = setColor;
}
});
})();

- would avoid the forming of the closure when the - augmentColor -
function was called the first time by each constructor and mean that
only one function object was ever created for each of the two functions
(rather than one for each prototype augmented).

Is there a reason for passing the - proto - parameter? Wouldn't -
instance.prototype - reference the same object?

But, do you find that you end up mixing styles?

Yes, but I would chose the style based on the situation so that is
inevitable.

I tried that and I found that the code became less clear
(and thus harder to go back to after a length of time)
as not every object was necessarily written in
the same style.

Except that if the style of code is chosen because it fits the problem
then reading a particular style tells you extra information about the
code. Well, that's one way of looking at it ;-)

How many iterations did you have to do in order to get a
timeable result? (Just curious, not trying to be cheeky.)

I did not do a formal timing of each (though I expect I will some time
soon). What I did was take a closure based object structure that
represented a script that produced barely acceptable performance on a
500 MHz PC (DHTML animation) and re-wrote it into standard public
member/ prototype objects (but otherwise exactly the same code) and
tested to see if it was better or worse than the original. It was worse
on all the browsers I tested with. Making a script that had been barely
adequate into a script that was unusable on the same machine. With the
only aspect of the scripts that could account for a difference in
performance being the time required to resolve the object public
properties as opposed to the outer function local variables in the
original.

Richard.

 

[Richard A. DeVenezia]

Richard A. DeVenezia wrote on 07 sep 2003 in comp.lang.javascript:

No, it is open.

http://www.crockford.com/javascript/javascript.html is the good stuff

http://www.crockford.com/javascript/index.html is that all seeing eye

 

[Richard Cornford]

Richard and I did one a while back on the use of eval versus splitting
and dividing. It was getting the value of a select list that was a fraction,
I needed it in decimal form. It took 10,000 iterations of each version
to see any real noticeable difference in the two versions.

I have tended to assume that for accurate speed comparisons the moor
iterations the better. In making test pages I usually allow the number
of iterations to be entered into a form field and then adjust it to the
largest figure that does not bring up the "a script on this page is
causing . to run slowly ." dialog (seems to take between 3 and 6 seconds
in IE).

As I recall testing string to number type converting it took 1,000,000
iterations to determine that unary plus is about 4% faster than
multiplication by one.

Richard.

 

[Code Ronin]

I can understand the desire to
wrap all the code that defines an object into one block structure,

Actually, I think that this is the issue underlying most arguments
about OO purity. It is not whether the _objects_ are structured
properly (which object augmentation accomplishes), but whether the
_source_code_ is structured "just so".

Some observations. The first invocation of the - augmaneColor - function
is going to form a closure that will contain a reference to the -
instance - object. Wouldn't that mean that the first object instance
cannot be garbage collected until the prototype (and, by implication,
the constructor function) is garbage collected, normally when the page
is unloaded?

You know, this is what happens when you keep a folder of old, sample
code around and not enough notes on the "whys". I believe the
"augmentColor" should have been:

augmentColor.call ( this, Foo, value );

function augmentColor ( cons, value ) {
this.color = value;
if ( ! cons.prototype.hasOwnProperty ( "getColor" )) {
...

You are concerned with the number of function objects

I would not characterize it as "concern". I just do not want to try an
OO purist way, which forces me to privatize properties and thus go
heavy in functions and closures.

created but are
still producing a separate - getColor - and - setColor - function for
each constructor that calls this method, though they are essentially the
same functions.

Yes, they are the same function, but I do want separate instances in
case I need to override the function. (I know, I know, that sounds
very "class-based".) It is really hard to give a short example, but
when writing up (personal notes) the Abstract Factory pattern for
JavaScript, I found that the "abstract class" (essentially an
augmentation function) might provide a default implementation for a
method, but the "concrete class" might have a pre-condition, that if
met, would then call the abstract class' implementation.

If you have the book "Applied Java Patterns", their example of the
Abstract Factory pattern is an AddressFactory. The idea is that you
are writing a PIM app and you need a way to create US addresses and
phone numbers versus addresses and phone numbers from other locales.
In the AbstractAddress class it implements the setPhoneNumber method
to ensure that the string passed can be parsed.

That method is overridden in the USPhoneNumber sub-class (of the
abstract class AbstractAddress). It defines that US phone numbers have
10 digits, so if the length of the string is exactly 10, call the
abstract class' setPhoneNumber method.

To accomplish this in JavaScript, I usually save the old function
object (created by the abstract (augmentation) function), create a new
function which references the saved function.

Now the USAddress needs to override in one way and FrenchAddress needs
to override in another...

To wrap up this long story, I consider duplicating function objects in
constructor function prototypes to be acceptable, but (generally) do
not do it for each object instance (i.e. this.getColor = function (
)...).

Is there a reason for passing the - proto - parameter? Wouldn't -
instance.prototype - reference the same object?

No, bad memory of where I placed the latest version of sample code,
and yes.

I did not do a formal timing of each (though I expect I will some time
soon). What I did was take a closure based object structure that
represented a script that produced barely acceptable performance on a

Was memory a concern also, or just performance?

With the
only aspect of the scripts that could account for a difference in
performance being the time required to resolve the object public
properties as opposed to the outer function local variables in the
original.

Given how it goes about finding properties in the scope chain, it is
understandable how it would take longer. It is interesting how you
went about the test and that is really good information. Thanks.

 

[Douglas Crockford]

By the way, if you have not already gone there, see

I want to thank you for this link. I am a newcomer to JavaScript,
coming from many years of OOP with Smalltalk and Ruby. I have been
having a hard time groking JavaScript's object model. The articles on
this link have triggered an epiphany that I will always be grateful for.

I am curious, Albert. What was the epiphany?

 

[Richard Cornford]

"Richard Cornford" <[email protected]> wrote in message

Actually, I think that this is the issue underlying most arguments
about OO purity. It is not whether the _objects_ are structured
properly (which object augmentation accomplishes), but whether
the _source_code_ is structured "just so".

I don't know about "just so" but there have got to be source
maintainability advantages in object definitions (as a whole) being
visually distinct. Which is not something that JavaScript imposes as
part of the language. But visually distinct might just be a matter of a
couple of cr/lf pairs at each end of the code and some appropriate
comments. I would never want to compromise the object structures because
of arbitrary restrictions placed on the source code.

augmentColor.call ( this, Foo, value );

Yes that makes much more sense.

I would not characterize it as "concern". I just do not want to
try an OO purist way, which forces me to privatize properties
and thus go heavy in functions and closures.

I see it as a trade off. You can go the private member/inner
function/closure route without being that heavy on memory (if you
understand what is happening), so if going that way has advantages that
outweigh the extra memory use that is unavoidable then why not? If there
is no advantage why waste the user's memory?

Yes, they are the same function, but I do want separate
instances in case I need to override the function. (I know,
I know, that sounds very "class-based".) It is really hard to
give a short example, but when writing up (personal notes)
the Abstract Factory pattern for JavaScript, I found that the
"abstract class" (essentially an augmentation function) might
provide a default implementation for a method, but the
"concrete class" might have a pre-condition, that if
met, would then call the abstract class' implementation.

To wrap up this long story, I consider duplicating function
objects in constructor function prototypes to be acceptable,
but (generally) do not do it for each object instance (i.e.
this.getColor = function ( )...).

I am not sure I understand the need for separate functions on each
prototype. Method overriding can be done by adding a method to an object
property so that it masks a method on that object's prototype (or adding
a method to the prototype so that it masks a method on
prototype.prototype (and so on up the prototype chain)). In principal
any overriding method could call a method in the prototype chain with -
apply - or - call - so it should not matter if that "abstract class"
instance was a couple of steps up the prototype chain and sharing a
single function object instance across every "class" that "extended" it.

Was memory a concern also, or just performance?

Memory use is a factor that I always consider and the closure based
objects were not too bad, having much of the initialisation code in
"private static" members and only one "privileged" and one "private"
method per object. But to be honest, in that case, if I had known a way
of trading more memory use for better performance I would have done so.
The script's performance really was just on the edge of acceptable.

Given how it goes about finding properties in the scope chain, it is
understandable how it would take longer. It is interesting how you
went about the test and that is really good information. Thanks.

That was how I read the theory, but I often have found that theory and
JavaScript implementations do not quite coincide so I though it worth
confirming.

Richard.