"VK" <schools_ring@yahoo.com> writes:
[color=blue]
> Lasse Reichstein Nielsen wrote:[color=green]
>> You would get the same effect by writing:
>> (function dummy(args){}); // you miss a ; after the void expression
>> window.onload = dummy;[/color]
>
> It wouldn't give this effect: parenthesis simply define *operator
> execution precedence* like (1+2)*3[/color]
Did you try it?
But you are right. Parentheses are used to override precendence of
operators in expressions.
And that's the point. By adding them, the result becomes an expression,
not a function declaration. Function expressions does not expose
their function names to the surrounding scope, and since the value
isn't captured anywhere either, there is no reference to the function
object created.
[color=blue]
> (function dummy(args){}); means "execute function definition first,
> then the rest". As the "rest" is not presented, parenthesis usage here
> is not really necessary.[/color]
It means "evaluate function expression". Had they not been there, the
parser would have parsed it as a function declaration, an entirely
different syntactic category, with quite a different semantics.
[color=blue]
> Function "dummy" is still properly parsed, allocated and *referenced*.[/color]
No reference is created to the anonymous (well, anonymous on the
outside) function. It is free to be garbage collected.
Had it been a function declaration, it would have created a property
of the variable object of the same name, referencing the function
object.
[color=blue]
> For some reason it breaks though the proper execution on FF and (as it
> seems) on Opera. They don't see "dummy" if parenthesis are used. There
> is nothing in ECMAScript specifications to endorse it,[/color]
Oh, absolutely. You don't think I came up with the idea myself, do you?
But for completeness:
FunctionDeclaration and FunctionExpression are defined in section 13.
Checking the semantics, you can see that only a FunctionDeclaration
adds a property to the current variable object, whereas
FunctionExpression with an identifier creates a new level on the scope
chain to hold the identifier, one that is only visible for the body
of the function, not outside. This is spelled out in the "NOTE".
[color=blue]
> so it must be a bug to report (if it's not reported yet).[/color]
No, it's behavior consistent with the ECMAScript standard.
Typically, when Gecko and Opera agree on something, and IE doesn't,
it's a safe bet that it's IE that isn't in compliance with the
standard.
[color=blue]
> IE acts properly:[/color]
.... as usual, when properly is defined as "what IE does" :)
[color=blue][color=green][color=darkred]
>> > Function variables instantiation happens in the execution order.[/color]
>>
>> Not sure what that means.[/color]
>
> Something like:
>
> function f() {
> alert(foo); // undefined[/color]
Uninitialized, but already existing! Had you written "alert(bar)", you
would have gotten an exception for using a non-existing variable.
[color=blue]
> var foo = 'bar';
> alert(foo); // 'bar'
> }[/color]
It is as if all variable declarations (i.e., the "var variablename")
in the function body were at the top of it. Assignments to the
variables, including those part of a variable declaration statement,
are executed in the order they are reached. So, the above function
is equivalent to:
function f() {
var foo;
alert(foo);
foo = 'bar';
alert(foo);
}
or even
function f() {
alert(foo);
foo = 'bar';
alert(foo);
var foo;
}
/L
--
Lasse Reichstein Nielsen -
lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
