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 anObject = funciton(){
return new Array();
}();
^- It is the pair of brackets after the function
expression that execute it (in-line and once only).
... "object doesn't support this action", ...
<snip>
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.
... . 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...
<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.
... I.e. it starts reading, and says
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"]
At the point of executing:-
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.
... I'm not used to classes, since in Actionscript everything
is essentially an object (or a prototype). I just saw it in your
code, and thought, well... Don't know what I thought, really
As Actionscript is an ECMA implementation everything that we have been
discussing to date will apply equally to Actionscript.
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;
}
}
- As you can see the class is a very concrete structure. It is also a
very final structure, once defined and compiled this class structure
specifies an exact template with which all instances of the Java
MyObject class will be drawn.
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();
}
MyObject.prototype.getIndex = function(){
return this.index;
}
MyObject.counter = 0;
MyObject.incrementCounter = function(){
MyObject.counter++;
}
MyObject.getNoOfInsts = function(){
return counter;
}
MyObject.prototype.getId = function(){
return this.id;
}
It is not a single structure but a sequence of statements. Its whole
does still act as a template with which all instances of MyObject are
created. That makes this combined definition of the MyObject
constructor, its properties and the properties of its prototype
analogous to the explicit class definition in Java. However, that
analogy is not explicit in the code, 'Class' is only a convenient
description for all of the interrelated code that is used to specify the
nature of a new object of that 'Class' created with the MyObject
function and the - new - keyword.
It is convenient for programmers who are familiar with object orientated
languages that explicitly define "Class" structures (such as Java) to
apply that term as a label for the totality of JavaScript code that will
be used to create object instances and to extend that label to include
the concept of an object being an instance *of* a particular Class (it
was created with a single set of instance defining code). So "Class" is
also used as a label for the "type" of an object (though JavaScript,
unlike Java, is loosely typed so the "type" that is named by the "Class"
is in the programmers understanding of the code and not a part of the
ECMA Script language, Internally it is just another Object).
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!"
Sorry, I am not going to say that until I can see that you have
understood the behaviour of the in-line one-off function call. You are
getting close and Lasse has posted a very explicit description so I am
confident that you will have it under your belt next time.
As far as precise explanations, that goes both ways. If I was better at
explaining then you might find understanding easier. Seeing where I fail
to get my point across helps me to refine my explanation, which makes
this whole exchange worthwhile in itself. I think that you are doing
your half of the conversation very well. In describing your
understanding at every stage I think that I can see which aspects of the
process I am failing to properly convey.
If nothing else, I truly understand why
alert(function(){ return function() { return true; }}()());
Gives me an alert box with "true" written in it.
Excellent! One more small step and your there.
Richard.
