But since I live in Denmark, the shipping is gonna cost me more than the
actual book, so I thought I might as well order a few books. So if you have
any suggestions to other good books you've read that one "simply must read",
I'd be glad to hear it :)

Thanks,
Daniel

PS: If you haven't seen "Waking Life", I heartily recommend it. It may turn
out to be pop philosophy, though (I don't have enough philosophy experience
to be a credible judge on that ;)

"self" might not be the best identifier to use because of the possible
confusion with "self" as a property of the global object that refers
back to that object. Lasse, for example, used - var myself = this; -
earlier in this thread. Douglas Crockford uses - var self = this; - as I
do.

The "self" or "myself" variables are named for the concept that they
represent. They hold a reference to the object instance so that inner
functions of the constructor can refer to their own object instance
(itself) when they are being executed in the global context. English
speaking programmers are burdened by the fact that the DOM properties
have been named with words relating to concepts in English. Danish
probably offers you a substitute variable name that would represent the
same concept but not risk causing any confusion with the DOM properties.
Along those lines you may have seen Douglas Crockford using "uber" in
his inheritance code because the English word "super" is a JavaScript
reserved word and cannot be used as an identifier.

I have been tending to deal with possible confusion from the other end
and creating my own reference to the global object with the identifier
"global" and using that instead of either "window" or "self" (though I
usually don’t use it in code that I post because that really would be
confusing).

I will start by trying to clarify the role of the on-off function call.
Consider:-

function exampleFunction(){
    return new Array();

- In this case a function is defined separately and then called, its
return value (a new Array) assigned to the global variable - anObject -.
The assignment of a value to the - anObject - variable is the very last
operation in the process and - anObject - does not know anything abut
what is happening on the right hand side of the assignment operator (-
= -). Now consider:-

var anObject = funciton(){
    return new Array();

- The function has changed from a function definition and is now a
function expression but the only consequence of that is that the
resulting function object is now anonymous (as it now has no identifier
by which it can be referenced) and the function object itself is not
created prior to the execution of this line of code. Apart from that
nothing has changed. From the left hand side of the assignment
operator - anObject - sees no difference at all, it ends up holding a
reference to an Array. On the right hand side of the assignment the
process has not changed; a function is being executed and the value that
it returns (the reference to a new Array object) is the result of the
operation and is assigned to the left hand side of the - = -. The
difference is that the code that defines the function is now in-line but
the nature of the objects involved is identical.

The one-off function in my example class script is just a normal
function object, it is executed and it returns a value. That value just
happens to be a reference to a function object.

Function objects do not recognise a distinction between constructor
functions and non-constructors. That distinction is only in the mind of
the code's author, which will influence how they use the function. If
the - new - keyword is used when a function is invoked the interpreter
will internally create an Object and make a reference to that object be
the - this - value during the subsequent execution of the function, and
then, in the absence of any other - return - statements, it will return
that object. If the function is invoked without the - new - keyword
the - this - reference will be determined by the context in which the
function is called and the return value is undefined if no explicit -
return - statement is provided.

function exampleFunction2(){
    var a = 'anyThing';
    //but no explicit return value.

alert( typeof exampleFunction2() ); //executed but alerts 'undefined'

alert( typeof new exampleFunction2() ); //called as a constructor and
                                        //             alerts 'object'

Obviously invoking a function that has a - return - value with the -
new - keyword is pointless as the Object that is internally constructed
and used as the - this - value is just wasted and gets thrown away at
the end of the function invocation.

function exampleFunction3(){
    var a = 'anyThing';
    return a;

alert( typeof new exampleFunction3() ); //called as a constructor but
                                        //             alerts 'string'
                       //The internally created object is thrown away.

So a constructor is just a normal function object, it is the use of
the - new - keyword that constructs a new Object and the way that the
function body is written that makes it suitable to be a constructor.

<snip>

You should not worry about that. To date you have managed to communicate
in English better than many native English speakers that I have known,
and having to read a sentence about the details of a programming
language more than a couple of times before grasping it is something
that I have plenty of experience of.

It also won't take you a fraction of a second to guess how good my
Danish is (hint: zero).

Thanks,
Daniel

That said, I did mean that the object was changed somehow, but I see your
point that everything stays the same (except from variable values,
ofcourse).

But still, I don't see the anonymity of the "original" MyObject function
being the result of function expression, since it isn't anonymous before
after it's been called. Up until that point it does exist as MyObject, as a
definition yes, but it still has a reference... To me, a truly anonymous
function expression would be something like

    myArray.sort(function(a,b){ return subCmp(a[label],b[label]); });

...And then you write this:

    var oneOff = function() {
        document.write("1");
        constructor = function() {
            document.write(" 2");
        }
        return constructor
    }();

    var test = new oneOff();

- I get "1 2", which means oneOff is parsed before the inner function, yes?
So, as I see it, if,

    var oneOff = function(){   /*code*/   }();

then,

    var varName = new oneOff();

can be read

    <varname> is assigned <anonymous function expression returning an
object>

- but the fact that the function expression is anononymous isn't known until
it's called (at least not to the parser, because it has a reference,
"oneOff", so how could it be anonymous?), which is why we're able to call it
at all, via the reference "oneOff". But, after it's called, "oneOff" is no
longer a reference to "oneOff", but to "constructor". This is where my image
of "reference hijacking" came from :P - before the first instantiation,
"oneOff" was a reference to a one-off function, but now it's a reference to
an object returned by the one-off function. I can see that the "hijacking"
term is bad because it indicates that it's the same reference that's been
"unplugged" from "oneOff" and "plugged into" the "constructor" function,
which probably isn't the case. But "oneOff" used to hold a reference to a
function definition, and now, after evaluating that definition, it holds a
reference to something else... Hm...

Also, realizing that I didn't properly understand the "one-off" term caused
me more and more grief, while I wasn't able to find any info on it in my
Bible or on Google. Before I finally looked it up in the dictionary
(should've done that first thing), I understood it as "more than one
statement/function executed in one go", but seeing it described as
"something done once only" cleared that up :) Except that it just added fuel
to my apparently false mind image of the reference being "hijacked", since
if it weren't, then the next time you'd use "new oneOff" you'd be calling
the same code again, and that would conflict with the term itself. I'm
confused :(

1)    var : "Aha, you want a variable, what should we call it?"
2)    objectInstance : "Great name!"
3)    = : "Okay, sure, let's assign it a value right away"
4)    new : "Oh, so you want an instance of an object, do you? Let's see
what that object could be."
5)    MyObject(); : "Well, I'll just evaluate that and get back to you"
[evaluating, finding the one-off function, evaluating it, doing parser
stuff, returning the constructor](*) "Okay, I have the guidelines now, let's
make that instance" [making an instance of the constructor, then assigning
it to "objectInstance"]

(*) And this is when all the magic ;) happens?

Am I really that far off or is it just my handicapped Javascript/English
vocabulary and my tendency to use (bad) metaphors damaging my ability to
write concisely? (Oh, thanks for picking me up about my English ;)

    var blahblah = function() {
        constructor = function() {
        };
        return constructor;
    }

    var myconstructor = blahblah();
    ^ That would become my "object constructor *function* object"

    var myinstance = new myconstructor();
    ^ And that would become my "object *constructor*"

I know that was terribly phrased, but my understanding here was that with
Mr. One-Off, I'd have just one call creating "myinstance" because One-Off
incorporates the "myconstructor" step in "blahblah" (I know that's not
exactly it or all of it, but that was the particular effect I was talking
about there)

Man, I really want the next words you say to be, "Actually I think you *do*
get it, Daniel, but for God's sake, man, work on your ability to precisely
explain what you mean!"

If nothing else, I truly understand why

    alert(function(){ return function() { return true; }}()());

Gives me an alert box with "true" written in it.

Argh! :) It's tough work getting smarter. But FUN!!!

Daniel

PS: Richard, thank you for all this, it's really great to have my mind
challenged - it's been a while ;)!

Or, as somebody once said: You haven't really understood something
before you can explain it clearly. (He was right!)

 var anObject = function(){...} ();

I think you are reading it as

 (var anObject = function(){...}) ();  

i.e., assign the function value to the anObject variable first, then
call it. This is syntacitcally illegal, since the "var" keyword makes
it a declaration, and declarations have no value. The correct way of
reading it, however, is

 var anObject = (function(){...} ());

i.e., create anonymous function, call it, and assign the return value to
the anObject variable.

I had to read it twice too, to be sure what happened. I would have put
the parentheses there to disambiguate.

1 : create anonymous function (a "function expression"):
       function() { document.write ... return constructor}
2 : call the function from 1
2.1 : execute  document.write("1")
2.2 : create an anonymous function (a "function expression"):
       function() {document.write(" 2");}
2.3 : assign the result of 2.2 to the new global variable "constructor".
2.4 : return the value of the global variable "constructor". This is the
      result of 2.
3 : assign the result of 2 to the local variable "oneOff".
4 : use the value of the variable "oneOff" as a constructor with
    no arguments (new ...()). That is, create a new object and
    call the function with "this" pointing to the new object.
4.1 : execute  document.write(" 2")
4.2 : since nothing is returned, the result of the "new"-expression (and
      the result of 4) is the new object.
5 : assign the result of 4 to the variable "test".

...

I sometimes wish there was a clone method on all objects, but one can
make it oneself:

 Object.prototype.clone = function () {
    function myConstructor = function(){};
    myConstructor.prototype = this;
    return new myConstructor();    
 }

"Lasse Reichstein Nielsen" <l...@hotpop.com> wrote in message
news:el17io4d.fsf@hotpop.com...

    var anObject = (function(){...})();

with (function(){...}) being evaluated first, then the return value of that
being evaluated by (); then the return value of that being assigned to
anObject.

But that's not entirely true, because at the point of assigning anObject a
value, which, as I understand, is what is happening here, I don't see any
evaluation being made just yet, at that point I see it as you put it, that
is:

    var anObject = (function(){...}();)

in the sense that at this particular instant in time, anObject holds a
reference to all definitions inside these parentheses, and these definitions
will stay "untouched" or "unexecuted" or "unevaluated" or "unprocessed" ;)
until anObject is called in another context. So when I say above that,
"...the return value of that being assigned to anObject", that would require
its invocation context to be simply:

    anObject();

However, the way we use it, as an object construct -

    var myInstance = new anObject();

- I see "...the return value of that being assigned to anObject", but
"anObject" in this context being nothing more than the courier of the
reference it holds inside, i.e. returns to an expression, i.e. assigns to
the given variable. In this context, to properly explain this with
parenthesis, I'd probably write a combination of the former two:

    ((function(){...})();)

- and lose the "var anObject" assignment part because that would be implied,
not as a variable holding the evaluated contents of the parentheses above,
but the yet unevaluated definition contents - the actual evaluation and
solution of the parentheses take place at that particular time and not
before.

That's pretty much how I understand that.

<snip>

Oh yes =)

Thanks mate!

Daniel

PS: I think this thread is getting really good reading for newbies trying to
understand stuff like this, don't you guys? Your expertise and my daftness
is a winning cocktail! We oughta write some books! ;)

"function (){...}" is a function *expression* (a sequence of
characters that match a production of the grammar called "function
expression"). It is an expression (rather than, e.g., a statement), so
it can be evaluated to a value.

That value is a function *value* (you say "return value", but there is
nothing being returned yet, the body of the function is not evaluated
at this point). Functions in Javascript are objects which have an
internal method called "[[Call]]".

"(function(){...})()" is again an expression, in this case a function
application. It consists of two parts, the *expression* before the
parentheses, which should (if the program is correct) evaluate to a
function *value*, and the argument expressions og which there are zero
in this case.

To evaluate a function application, first evaluate the expression in
the function-position. In this case it is a function expression, so
it directly evaluates to an (anonymous) function value. Then evaluate
the arguments, in this case it is trivial. Finally, call the function with
the arguments. At this point, the body of the function is evaluated.
The reteurn value of *that* is the value of the application expression.

"var anObject = function(){...}();" is not an expression, it is a statement.
More precisely, it is a "variable declaration and initalization" statement.
The Javascript interpreter already noticed that "anObject" was declared
as a local variable, it checks that before executing anything, so the scope
of the variable can precede its declaration.

To find the effect of a statement, it is executed (not evaluated, as
it doesn't have to have a value). To execute an assignment (what an
initialization statement really is), you first evaluate the right-hand
side expression. In this case, it is the return value of calling the
anonymous function. Then, and only then, is the "anObject" variable
bound to that value. Until this, it has been undefined.

That value, the return value of the call to the anonymous function
(which we have no reference to otherwise[1], so it will never be
called again) just happens to be a function itself, a completely
different function.

Needless detail on how objects are created:

Objects are, obviously, an important datatype for Javascript. As I
said earlier, functions are objects with some extra functionality, and
so are Regular Expressions and a lot of other utility objects.

All objects have a property called "constructor". It refers to the
function that was (or could have been) used as a constructor to create
the object. If you write "var x={};" then "x" refers to a new,
(almost) empty object. The constructor for it is the one called
"Object". The constructor of an array is "Array", and so on.

Each function can be used as a constructor and therefore has a
property (remember, they are objects too) called "prototype". When you
look for a property of an object, it first checks if the object has
had that property assigned to it. If not, it checks if it is a
property of its prototype, and if not, it continues down the prototype
chain (I haven't checked where it ends, but probably at Object.prototype).

Quiz: What does the following do?
---
 var x = new Object();
 Object.prototype.foo = 42;
 alert(x.foo);
---

When you call a function as a method of an object, the "this" keyword
will refer to that object. That is:
---
 var x = new Object();
 x.foo = function () {return this;};
 alert(x == x.foo());
---
will alert "true".
It is the "." notation (or the equivalent []-notation) that marks a
function call as a method invocation. If you changed the above to:
---
 var x = new Object();
 x.foo = function () {return this;};
 var bar = x.foo;
 alert(x == bar());
---
it alerts "false", even though "x.foo" and "bar" both refer to the
exact same function object. It is the way the function is called that
sets the "this" keyword's value. When you call a function directly,
and not as part of an object, then the "this" keyword refers to the
global object, where the global variables live.

Since there are no classes in Javascript, the term "constructor" might
also be a little misleading. As I said, any function can be used as a
constructor. What happens when you write
 new foo(42);
is that you call the function "foo" with the argument "42". However,
where a normal function call of that kind would have set the "this"
reference to the global object, and a method invocation would set
"this" to the object of the method, the "new" makes sure that the
"this" keyword refers to an entirely new object. If the foo function
doesn't return something (or if it returns something that is not an
object), that new object is the value of the entire expression. If
it returns another object, they object will be the value of the "new"
expression.

---
function foo(x) {
  this.n=x;

var o1 = new Object();
o1.bar = foo;
o1.bar(42);      /* sets this.n = 42 with this == o1 */

var o2 = new foo(87); /* sets this.n = 87 with this == new object == o2 */

alert(n +","+ o1.n +","+ o2.n);  /* alerts "37,42,87" */
---

Ops, that's my fault. If you look closely at the way I have spelled
function you will notice that the t and the i have been transposed. One
of the hazards of touch typing into a word processor instead of a
syntax-highlighting text editor. Though I am surprised that I did not
notice Word complaining about the spelling, but there is a tendency to
ignore highlighted spelling mistakes when entering code in Word. Sorry
if that was confusion, correct the spelling an it will work as
advertised.

<snip>

My reason for stressing that the assignment operation had a left hand
side (var MyObject) and a right hand side (all the rest of the
statement) was to try and explain how MyObject was only ever assigned
the end result of the right hand side. There is not "hijacking" because
the only value that is ever associated with the MyObject variable is a
reference to a function object that was originally created as the inner
function "constructor" within the execution context of the one-off
function execution.

You seem to be seeing too much happening at once and Lasse is right,
parenthesising the original statement should make the real sequence of
events clearer.

ECMA script assigns precedence to various operations, so while:-

alert( 1 + 2 * 4 );

- could alert 12 or 9 in practice it always alerts 9 because the - * -
operator has higher precedence than the - + - operator. The order of
evaluation of an expression can be altered by using parentheses to
bracket the addition operation - alert( (1 + 2) * 4 ); - which alerts 12
because the addition Is forced to happen before the multiplication
instead of after. Because ECMA Script defines precedence for operations
the original alert statement can be bracketed as - alert( 1 + (2 *
4) ); - and still produce the original result 9. That arrangement of
brackets can be considered the "natural" parenthesising of the
expression. So:-

var MyObject = function(){ . . . }();

- (as a shorthand form of the original example) can "naturally" be
parenthesised as:-

var MyObject = ( ( function(){ . . . } )() );
                                            ^- notice that the
                       statement terminating semicolon must be
                       outside of the parentheses for this to
                       remain legal JavaScript syntax. In the
                       same way as the - var - cannot be placed
                       within parentheses.

For the interpreter to discover what value to assign to the MyObject
variable it must evaluate the whole of the expression on the right hand
side of the - = -, the contents of the outer set of brackets. The
evaluation of the contents of the outer set of brackets must start with
the contents of the innermost brackets, which contain - function(){ . .
. } -, a truly anonymous function expression. Anonymous because once the
function object has been created the _only_ reference to it is the
result of the evaluation of the innermost bracketed expression. If we
refer to the result of the evaluation of the innermost set of brackets
as - temporaryInternalFunctionReference - and replace those brackets
with that we get:-

var MyObject = ( temporaryInternalFunctionReference() );

The next stage in the process is the evaluation of the contents of the
remaining set of brackets. That step is the execution of the function
object referred to by the result of the evaluation of the contents of
the inner set of brackets. That function is the outer function so the
result of executing it is its return value, the inner function
"constructor" that may later be used as an object constructor.

Having fully resolved the right hand side of the assignment operator,
and acquired the reference to the inner "constructor" function as the
result, The last part of the process is to assign that value to the
MyObject variable.

Up until that final assignment of the reference to the inner
"constructor" function object MyObject has not referred to anything. It
has also never known anything about what is going on to the right of
the - = - operator.
From that point on MyObject can be used with the - new - keyword to
construct objects because it refers to a function object, and because
that function object has been created with code that is appropriate to
an object constructor (and has had additional methods assigned to its
prototype) using - new MyObject("anyString"); - is a reasonable thing to
do and will create a usable object.

<snip>

var objectInstance = MyObject();

- the MyObject variable already contains a reference to the inner
function that was defined with the name "constructor". The one-off
function has already been executed and done its work, At this point The
one-off function has no accessible references and will never be executed
again.

<snip>

Classes are a concept that is explicit in other object orientated
languages like Java but there is nothing within ECMA Script that
explicitly represents a class.

For comparison, if my original MyObject Class was defined in Java it
would look something like:-

public class MyObject{
    private static int counter = 0;
    private static void incrementCounter(){
        return MyObject.counter++;
    }
    public String id;
    private MyObject self;
    private int index;
    /* class constructor. */
    public MyObject(String id){
        this.id = id;
        this.self = this;  //not needed in Java!
        this.index = MyObject.incrementCounter();
    };
    public int getIndex(){
        return this.index;
    }
    public static int getNoOfInsts(){
        return MyObject.counter;
    }
    public String getId(){
        return this.id;
    }

The template for an ECMA Script object is much more loosely defined, and
it is also mutable (though you wouldn't often want to do that). If my
original class was defined in the more traditional JavaScript way, as a
separate constructor function and as properties of that function and its
prototype object (the private members must now be public members as
there are no closures to contain them), the results would look like:-

function MyObject(){
    this.id = id;
    this.self = this; //pointless in an object with no inner functions
    this.index = MyObject.incrementCounter();

"Lasse Reichstein Nielsen" <l...@hotpop.com> wrote in message
news:vfujgtrj.fsf@hotpop.com...

For each function call, the interpreter creates a local scope, the
so-called "variable object", where the parameters and local variables
are properties. These variable objects are not accessible from
javascript, so you cannot use them as objects in your code, they are
merely described as objects in the specification. That allows
implementations to optimize these objects.

The global object is different, since it can be, and typically is,
visible to the javascript code.

One of the properties of the global object in browsers has the name
"window". That is why you can write "window" directly in Javascript -
it is a global variable, i.e., a property of the global object.

The value of the "window" property is a reference to an object. It
is in fact a reference to the global object itself. So is the "self"
property, and in some cases also "parent" and "top". The global object
would survive, even if you changed what all these references points
to.

If you write
 x=y;
and neither are declared as local or global variables, then you get an
error. When no variables are declared, the "y" is checked in the global
object, and it doesn't exist, so you can't find its value. That is an error.

You could write "window.y" which would merely give "undefined", because
that is property access, not variable lookup, even though the resulting
property would be the same.

If "y" was defined, but "x" wasn't, then "x" would also be searched
for in the global object. However, it is not an error that it is
undefined, since we don't attempt to read it. Instead a new property
called "x" of the global object is created, and the value of "y" is
stored in it.

When javascript code is evaluated, the global object is the "window"
object (or really the opposite: the "window" object is the global
object) of the window from which the code was called.

In other words, the final knot I needed to tie (should've been the first
knot) was that after something like this -

    var blahblah = function() {
        constructor = function() {
        };
        return constructor;
    }();

- blahblah already holds the reference to constructor, and I wanted it to
hold a reference to the function expression until blahblah was called for
the first time. Which is also why the hijacking term was not only confusing
but plain out wrong - there's no reference to hijack =)

I also think that I held on to that illusion so long because I couldn't see
anything functionally proving it to be false, the difference between
illusion and fact was essentially the point of time the anonymous function
was "evaluated" or "executed", and delaying the evaluation demanded that a
ficticious reference to the function expression had to exist. If such a
reference did indeed exist, and it worked the way I wanted it too, I don't
think it would've caused any programmatical problems (at least not in this
context), it would probably just require a rewrite of the Javascript
specifications ;)

The facts are much more logic and easier to understand - it's kinda funny
(or, very irritating ;) that I didn't see them the first time.

And here:

At least now, I TRULY truly understand it ;)

Thank you, both of you!

Daniel

"Lasse Reichstein Nielsen" <l...@hotpop.com> wrote in message
news:isqi4gbd.fsf@hotpop.com...

Thanks for this, I've really learned alot these few days =) This shouldn't
be called a newsgroup, it should be a class-is-in-session-group ;)

I think I'm about ready for a nice, long weekend =)

Daniel

function TestObject(){
    this.getIndex = getIndex_TO;

TestObject.prototype.incIndex = function(){
    this.index = this.index + 1;

getIndex_TO = function(){
    return this.index * 4;

It would be reasonable to say that the first 50 TestObject instances are
not the same "Class" as the next 50, or to say that the "Class" has
changed. It is more likely the case that if you don't treat your object
defining code as immutable then the whole "Class" concept does not
really fit in with JavaScript at all.

Under the vast majority of circumstances modifying the code that will be
used to define a new Object of a particular "Class" is not something
that you would want to do. So "Class" as a concept will fit with
JavaScript. On the other hand, being able to modify it introduces some
interesting and potentially useful possibilities. Consider executing:-

var a = new TestObject();
var b = new TestObject();
a.incIndex();
TestObject.prototype.index = 5;
var c = new TestObject();
alert('a.index = '+a.index+
     ' b.index = '+b.index+
     ' c.index = '+c.index)

- with the original TestObject code. When initially reading the -
this.index - value the objects are reading the value from their
prototype. When the - incIndex - method increments the index it will set
a property of the object with the name "index" (masking the value on the
prototype). So changes to the value on the prototype impact upon objects
created before the change was made, but only if they have not already
executed their - incIndex - method and cut themselves of from reading
the value on the prototype.

Of course it is not going to be easy to usefully exploit the fact that
JavaScript offers that level of flexibility.

<snip>

<snip>

<snip>

Richard.
--

I like the idea for being able to easily clone objects but I would
define a clone along the lines of a copy of a snapshot of an object at
the instant it was cloned. This clone method does not do that in fact
its behaviour is much more interesting.

Creating object A as - {x:1} - and then calling - var B = A.clone(); -
gives a clone of A which, if queried for its - x - property, will read
the property from its prototype (object A), so B.x == 1. However,
setting - A.x = 2 - and then reading B.x will give 2 because 2 is now
the value of the - x - property on B's prototype. Of course if - B.x -
is set then the property will be created locally on the object and it
will no longer be read from the prototype and so no longer reflect
changes made to that property on A.

That makes B more of a "live" copy of A as it will initially reflect the
current property values of A but slowly diverge as its own properties
are set and mask out those on its prototype.

Objects that exploited Douglas Crockford's closure based technique to
create private instance members would also produce some odd effects with
this code. Calling one of Douglas's "privileged" methods on a clone may
alter the clone by using the - this - keyword while still interacting
with the private members of the object that was cloned.

While mulling over the possibilities for exploiting these two new and
interesting object structures it dawned on me that there is a second
method of providing private static members in JavaScript. My first
method worked because all objects created with a constructor shared the
same constructor function and so could share the same closure formed
this that constructor. But equally all objects created with a
constructor also share that constructor function's prototype. So a
closure formed with the prototype cold also serve as a repository for
private static members. Something like:-

function MyObject(v){
    this.value = v;

This is actually the object behaviour I know from Actionscript (although I
didn't understand it as thoroughly before this thread), so I'm really glad
to see it's the same behaviour :)

Good to have my weekend with that one over :)

Have a good one!

Daniel