f ?
Jorge
window.onload= function () {
var a= 0;
function f () { alert("cero") };
if (a === 1) {
function f () { alert("uno") };
} else if (a === 2) {
function f () { alert("dos") };
} else if (a === 3) {
var f= function () { alert("tres") };
}
f();
};
</script></head><body></body></html>
(FF2, FF3) -> cero.
(Safari, Opera, IE) -> dos.
--Jorge.
Jorge
window.onload= function () {
(function (f) {
if (false) {
function f () { alert("uno") };
}
f();
})(function () { alert("dos") });
};
</script></head><body></body></html>
(FF2, FF3) -> dos.
(Safari, Opera, IE) -> uno.
--Jorge.
Richard Cornford
If you want to ask a question putting that question in the form of words
will make the situation a lot clearer (a real subject lien that states
the subject of your posts is also a good idea).
ECMAScript syntax does not allow a function declaration inside a block
statement. However, ECMA 262 does allow implementations to provide
syntax extensions. Thus where something (anything) would be a syntax
error in ECMAScript it may be meaningful and non-error producing in any
implementation. An implementation is required to behave as specified
where specified but any gap in the specification may be filled with
additional features/facilities. The problem with in terms of
cross-browser scripting is that there is nothing that requires different
implementations to put the same things into those gaps.
JavaScript(tm) has a syntax extensions that is a FunctionStatement, and
being a statement it may appear inside a block statement, and so it may
be conditionally evaluated during the execution of code for the
execution context in question.
JScript(tm) has a syntax extensions where function declarations that
appear in contexts where ECMAScript would regard them as syntax errors
are treated as function declarations regardless of that context. These
function declarations are treated as function declarations and process
during variable instantiation for the execution context (before the
execution of any of the code for that execution context). Thus if
multiple 'function declarations' share the same name the one that ends
up being referred to by the declared name is the one resulting form the
last declaration in the source code for that execution context (the
result is independent of the later evaluation of the block statements
and so is unconditional).
Because the vast majority of web developers have a near negligible
understanding of any of the technologies involved they write code that
relies upon these syntax extensions (the results may only work by
coincidence but if they are shown to work on 'common' browsers that is
good enough for those authors). Thus the manufactures of other browsers
will tend to imitate the syntax extensions of the common browsersin
order that their browsers do not appear broken when exposed to this
code. But given two different syntax extensions in two common browsers
which one will be imitated by other browsers is not predictable, and
will not necessarily be consistent over time.
As ECMAScript allows the conditional evaluation of function expressions
and the assignment of the result to variable in the containing scope it
is never necessary to place a function declaration inside a block
statement and so inconsistent and unpredictable outcomes can be totally
avoided. And the general rule is that if you are trying to create
cross-browser code it is a very good idea to restrict the code so that
it only uses syntax specified in ECMA 262.
Richard.
Jorge
wrote:
>
> If you want to ask a question putting that question in the form of words
> will make the situation a lot clearer (a real subject lien that states
> the subject of your posts is also a good idea).
Still, you got it perfectly. Now it's clear as an unmodied lake.
Hopefully there won't be many more gaps in forthcoming ECMAScript
specification(s).
Thank you,
--Jorge.
Richard Cornford
>On Jul 20, 6:32 pm, Richard Cornford wrote:
>> If you want to ask a question putting that question in the form
>> of words will make the situation a lot clearer (a real subject
>> lien that states the subject of your posts is also a good idea).
> Still, you got it perfectly. Now it's clear as an unmodied lake.
But do you expect to be given the same leeway after you have been
warned?
> Hopefully there won't be many more gaps in forthcoming ECMAScript
> specification(s).
There will be thousand of similar possible syntax constructs that have
no specified meaning in the new specifications, and there will be
explicit provision for syntax extensions. Brendan Eich sees extensions
as a good thing and nobody has argued a strong counter-case yet. And the
fact that we have been coping with syntax extensions for the past decade
or more suggest that they are not such a bad thing. Many developments in
the language (such as function expressions) appear to have started out
as syntax extensions that were later formalised.
And the specific issue of 'out of context' function declarations is to
be left precisely as it is now in the ES3.1 spec (except for its
'strict/cautious' mode where it is proposed that multiple declarations
of like-named functions within a single scope will generate an error
when compiled (although it is possible that such a restriction will not
be applied if those declarations appear in a location where the spec
does not allow them (the spec cannot specify the handling of unspecified
constructs))). There is no desire to formalise either of the existing
syntax extensions, and that would declare the other existing possibility
as being formally 'incorrect'.
Richard.