Can JavaScript use a function before it's defined?
Jonathan Fine
Here's a file
===
$ cat wierd.js
f()
function f(){print('hi')}
f()
function f(){print('ho')}
f()
===
And when I run SpiderMonkey on it
$ js wierd.js
I get - well, what do you think I get?
OK. So I get
===
$ js wierd.js
ho
ho
ho
===
So it seems that SpiderMonkey is picking up the LAST definition of f()
and executing it three times. Not at all what I expected.
I didn't find any relevant information in
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions#Defining_functions
I'd like to read about this. Any pointers? In particular, does anyone
know of a JavaScript book that documents this behaviour? And is it
reliably cross-platform?
--
Jonathan
VK
> As subject. By 'before' I mean before in the file, not in time.
>
> Here's a file
> ===
> $ cat wierd.js
> f()
> function f(){print('hi')}
> f()
> function f(){print('ho')}
> f()
> ===
>
> And when I run SpiderMonkey on it
> $ js wierd.js
> I get - well, what do you think I get?
>
> OK. So I get
> ===
> $ js wierd.js
> ho
> ho
> ho
> ===
>
> So it seems that SpiderMonkey is picking up the LAST definition of f()
> and executing it three times. Not at all what I expected.
>
>
> I'd like to read about this. Any pointers? In particular, does anyone
> know of a JavaScript book that documents this behaviour? And is it
> reliably cross-platform?
Yes, this behavior is by design and cross-browser. Do not forget that
function declarations are not a part of the program execution flow.
I am not ready to give an exact reference. I assume you can find
relevant text in ECMA-262 3rd ed. in the description of parser and
tokenizer algorithms. Basically it is because the code being parsed
and pre-compiled (tokenized) in full before to start the execution.
This way no matter how many functions f you have declared, they will
be consecutively replaced in the order they appear in the source code,
so finally only the last one will be stored. At the same time all f()
calls will be also tokenized to [call function f]; so when the
execution will start you'll get three [call function f] tokens
executer one by one, with only one [function declaration f] token.
I am not sure what are you trying to do, but if you really need three
functions f being executed and overridden one by one, then the first
option could be to include these functions into the execution flow by
using function expressions instead of function declarations:
(function f() {window.alert(1);})();
(function f() {window.alert(2);})();
(function f() {window.alert(3);})();
There is a difference of how IE and others handle function
expressions, so by the end you'll have function f declared in IE but
not in say FF.
With a description of your actual intent a regular coding solution
could be suggested.
Jonathan Fine
> Yes, this behavior is by design and cross-browser. Do not forget that
> function declarations are not a part of the program execution flow.
Thanks for this. I guess there may be a difference between function
declaration and function definition. For example
f = function f(){print('hi')}
is not always equivalent to
function f(){print('hi')}
I was expecting the latter to have the actual meaning of the former!
> I am not ready to give an exact reference. I assume you can find
> relevant text in ECMA-262 3rd ed. in the description of parser and
> tokenizer algorithms.
[explanation snipped]
I'd really appreciate a reference that gives all these not-so-obscure
gotchas in JavaScript language, so that I know where to look the next
time I come across a gotcha like this.
> With a description of your actual intent a regular coding solution
> could be suggested.
I wanted to understand why SpiderMonkey was not doing what I expected.
I wrote:
// Dummy definition
if (typeof fn == 'undefined') function fn(){}
// Lots of lines like ...
fn(123)
// Real definition of fn
function fn(){
print(arguments)
//...
}
I thought this would allow me to structure the code in the way I wanted
to, and was surprised that the dummy def'n of fn was never used.
Thank you for your help in understanding some of the intricacies of
JavaScript.
--
Jonathan
RobG
> VK wrote:
> > Yes, this behavior is by design and cross-browser. Do not forget that
> > function declarations are not a part of the program execution flow.
>
> Thanks for this. I guess there may be a difference between function
> declaration and function definition. For example
> f = function f(){print('hi')}
> is not always equivalent to
> function f(){print('hi')}
>
> I was expecting the latter to have the actual meaning of the former!
They are essentially equivalent, the difference is that function (and
variable) declarations are processed before any code is executed.
Function expressions, e.g.
var foo = function() {}
are evaluated when the code is run. In the above, when execution
begins, foo has a value of undefined until the line assigning it the
anonymous function is executed.
>
> > I am not ready to give an exact reference. I assume you can find
> > relevant text in ECMA-262 3rd ed. in the description of parser and
> > tokenizer algorithms.
>
> [explanation snipped]
>
> I'd really appreciate a reference that gives all these not-so-obscure
> gotchas in JavaScript language, so that I know where to look the next
> time I come across a gotcha like this.
It's not a "gotcha", it is a well-known feature of the language and is
not unique to ECMAScript. Try section 10 Execution Contexts and more
specifically, section 10.1.3 Variable Instantiation.
>
> > With a description of your actual intent a regular coding solution
> > could be suggested.
>
> I wanted to understand why SpiderMonkey was not doing what I expected.
>
> I wrote:
>
> // Dummy definition
> if (typeof fn == 'undefined') function fn(){}
>
> // Lots of lines like ...
> fn(123)
>
> // Real definition of fn
> function fn(){
> print(arguments)
> //...
> }
>
> I thought this would allow me to structure the code in the way I wanted
> to, and was surprised that the dummy def'n of fn was never used.
Because before the code was executed, the function declaration had
been processed as a component of variable instantiation and fn was a
function object.
To get the effect you expected:
var fn;
// Dummy definition
if (typeof fn == 'undefined') function fn(){}
// Lots of lines like ...
fn(123)
// Real definition of fn
fn = function (){
print(arguments)
//...
}
--
Rob
Joost Diepenmaat
> VK wrote:
>
>> Yes, this behavior is by design and cross-browser. Do not forget that
>> function declarations are not a part of the program execution flow.
>
> Thanks for this. I guess there may be a difference between function
> declaration and function definition. For example
> f = function f(){print('hi')}
> is not always equivalent to
> function f(){print('hi')}
>
> I was expecting the latter to have the actual meaning of the former!
Well, javascript is kind of a hack - but then, many popular languages
are. In any case, as a rule of thumb, "function name() {}" is
evaluated at the earliest possible time, while "name = function(){}"
is evaluated at the latest possible time.
All of the above is a convenient lie.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/