Function declarations in statements

liorean liorean at
Fri Mar 16 22:12:03 PDT 2007

On 17/03/07, Brendan Eich <brendan at> wrote:
> I've never seen web content that uses a named function expression and
> expects the name to be bound in the variable object of the execution
> context.

Me neither, and I'm a member of several JavaScript forums and mailing lists.

> I don't recall any such bug ever being filed with
> We always implemented ES3, which says that the
> name binds in an Object instance created to scope the function object
> in its context's scope chain, so that the function can refer to
> itself. Sorry to belabor the obvious for those of you who know ES3.

Yes. Microsoft seems to have missed that particular thing when reverse
engineering JavaScript.

> The IE JScript bug should be fixed. It's just a deviation from the
> standard, as far as I can tell.

A JScript bug I've been bitten by after writing a painfully long
script looking mostly like this;

        bar:function f(){
            /* bar code */
        baz:function f(){
            /* baz code */

Easy to fix (s/(f,/(arguments.callee,/), but irritating. Never seen
anyone bitten by it in the reverse direction, though.

What I'm arguing for here is that these compile time instantiations
(in if..else and with in particular) defies programmer expectations.
They can lead to outright bugs in programs, because they silently
change the meaning of the program from developer expectations. NOBODY
expects a function declared in the else-path to override the function
declared in an if-path for a function call that may even be happening
inside the same if-path. A syntax error would even be preferable to
that behaviour, but run time instantiation would of course match
programmer expectations best. So, it would be nice if ES4 actually
addressed this.
David "liorean" Andersson

More information about the Es4-discuss mailing list