Frederik said:
alex schreef:
The new Function syntax has a bad performance
Not true, there are environments where using the Function constructor is
the quickest method of creating a function object.
and shouldn't be used in general. It's only use is
when the code of the function has to be made
in run-time.
Function objects created with - new Function - do not adopt the scope
chain of the execution context in which they are created for their
[[Scope]] property, so they should be used when the closures produced by
the alternatives need to be avoided.
The second one creates a function named f, this function
will be available in global scope IIRC.
Function declarations result in the creation of a function object as a
property of Variable object for the execution context in which the
declaration appears. Thus function decelerations that appear inside
other functions are not globally available.
The third one creates a function without name (anonymous),
and assigns it to the variable f. This way the function is
in the scope of the variable f.
A function object created with either a function declaration or a
function expression has its assigned its internal [[Scope]] property
assigned the scope chain that applied at the moment of its creation. So
it would be more reasonable to say that - f - is in the scope of the new
function object.
Note that you should place a semi-colon after an
assignment, this way:
var f=function(x,y){
return x*y;
};
Note: that as javascript has automatic semicolon insertion advice to add
semicolons in location where automatic semicolon insertion would add
them automatically is 'best practice' advice not a requirement. (It is a
best practice that I agree with, but should not be stated as anything
more.)
This is not required as with all javascript statements
(you can do alert(x) without semi-colon)
Expression statements should all be semicolon terminated, and when -
alert(x) - is followed by a new line starting with a token that cannot
form part of an expression with - alert(x) - (or a closing brace) then a
semicolon will automatically be inserted after it. On the other hand:-
alert(x)
(b = (x - 1));
- will produce a runtime error as without the semicolon at the end of
the call expression - alert(x) - the whole becomes a call expression
where an attempt is made to call the return value from - alter(x) -,
which is undefined and so not executable.
but you should do this conventionally.
You could also do
obj.f = function(x, y){
return x*y;
};
Then, the function f will be a member of the object 'obj'.
From the point of view of the created function object there is no
distinction between its being referred to by a property of the Variable
object for the current execution context and its being referred to by a
property of your - obj - object.
There is also a fourth one like this:
var f=function fName(x,y){
return x*y;
};
This way, a function named fName will be create, and
assigned to the variable f.
It will be in the scope of the variable f. I'm not sure
what happens to the fName function however, is it still
available in global scope?
The 'names' of functions created with function declarations are not
necessarily globally available so this concern is not real. Officially
(by specification) the use of an optional Identifier with a function
expression causes an extra object to be added to the scope chain of the
execution context in which it is being evaluated and the name used as a
property of that object. This extended scope chain becomes the function
object's [[Scope]] property and a reference to the function object
assigned to the named property of the object added to the scope chain.
The object added to the scope chain is then removed following the
creation of the function object. Thus the only code capable of referring
to the function using the name specified with the optional Identifier is
the code within the function body.
In practice this is an area where implementation bugs are common and
many environments create a new named property of the Variable object for
the execution context in which the function is created and assign a
reference to the newly created function to that property.
This fourth way is useful for debugging, as the error stack
will show the names of the functions instead of anonymous.
But the buggy implementations make this a potentially undesirable
trade-off against writing code that will behave differently in different
environments.
It is also interesting that you deprecate the use of - new Function -
out of some impression that it may not perform well but propose a form
of function expression that implies a runtime overhead that has no
benefits beyond debugging (and its own potential for introducing bugs
due to the leaking of the function names into containing scopes in buggy
implementations).
An important aspect of the creation of the function objects not
mentioned here is when that creation happens (of particular relevance
when in the case of function declarations and function expressions the
internal [[Scope]] properties of the objects will be assigned the scope
china that applies at the moment of creation). Function objects created
with - new Function - and by the evaluation of function expressions are
created when the pertinent lines of code are executed, while with
function declarations the function object is created during 'variable
instantiation', prior to the execution of any statements in the
pertinent execution context. Thus:-
a();
function a(){
...
}
- works because the function declaration results in the creation of a
function object, and the creation of a property of the Variable object,
named 'a' and that refers to the function object, before the line of
code that calls - a - is executed. While:-
var a;
a();
a = function(){
...
};
- does not work because the attempt to call - a - happens before any
value has been assigned to the 'a' property of the variable object.
Richard.
