dhtml said:
The example I provided was not complete HTML.
I know that, yet it purported to support an assertion about the relationship
between HTML and scripts executing the same browsers. That makes it quite
important to show the mark-up concerned. Party to allow the reader to verify
that the effect described is not an artefact following from the use of
structurally invalid mark-up and partly to render the significant aspects of
the context unambiguous. For example, if the order of the mark-up in my
example is modified such that the DIV element's declaration follows the
SCRIPT element the outcome becomes very different. If you try that you can
observe that the assignment to an undeclared Identifier during the execution
of global code in a proceeding script element is not modified by the later
parsing of a DOM element with an ID that corresponds with the Identifier
used.
The example you provided was more detailed,
Only in the sense that it put the code you posted into an HTML mark-up
context and changed the alerts you used (which are problematic when used for
this type of analysis as they shift focus in the GUI and are not always
obvious about the sequence of events) into - document.write - calls. The
result demonstrated that the outcomes you asserted were not observed using
the code that contained them.
but misconstrued my point
(which had to do with namespacing).
If you don't clearly sate what your point is (or answer that question when
asked) you are going to get judged on the material you do post.
Ok, so you want to talk about it in depth...
I don't want to talk about it much, and I can think of many better People to
talk about it with in the event that I did (and some worse, e.g. VK).
<div id="out">
<script type="text/javascript">
document.write(out+'\n\n');
</script>
Result is "[object]"
In IE.
<script type="text/javascript">
What happened to the DIV element this time. Are we taking this example as
providing a SCRIPT element to be substituted for the SCRIPT element in the
previous example or is this one intended to be executed without a IDed DIV
element in the mark-up?
document.write(out+'\n\n'); //undefined.
try {
var out = function() {};
} catch(ex) { alert( ex.message); }
document.write(out+'\n');
</script>
Result:
"undefined"
"function(){}"
So what is it that this code is supposed to illustrate. It shows that if you
declare the variable you don't have problems with exceptions being thrown at
assignment, and if the DIV element had been shown to proceed the SCRIPT
element it would have illustrated the IE bug where variable installation for
declared Identifiers is modifying the Variable object in the global
execution context where the spec says it should not. (though that bug has no
real baring on the issues that follow from IE throwing exceptions in some
circumstances when IDed DOM elements correspond with undeclared global
variables.)
When the execution context is entered in that script tag, the
var out statement declares a property named |out| with the
value undefined.
No, the spec says that, for a variable declaration, a property is only to be
created and undefined assigned to that property in the event that the
Variable object does not already have such a property. That is quite
important as is specifies behaviour in the event that formal parameters,
function decollations and variable declarations attempt to use the same
Identifiers. Specifically, that function declarations will replace the
values of formal parameters but variable declarations will not replace the
values of either formal parameters or function declarations. But because the
specification is in terms of the interaction with the Variable object (and
pre-existing properties of the Variable object) it should apply to whichever
object is the Variable object, even when it is the global object.
Next, there is an assigment to out. a functionExpression.
No, the assignment of the result of evaluating a FunctionExpression to -
out -, The assignment itself is an ExpressionStatment.
IE has a bug here, that much is true.
And not significant to the question of whether exceptions will be thrown.
If you're saying that
if there's an element id that IE should create a property
of the global object, and subsequently declaring var
[insert_elements_id_here] should throw an error, well,
I would disagree with that statement.
I didn't even imply that. The actions taken in response to variable
declarations during variable instantiation should not modify pre-existing
properties of the Variable object. In the global execution context the
global object is used as the variable object, so the values of its
properties should not be modified. If they are then that is a bug, though
not a particularly important one (as when you declare a variable the odds
are pretty good that you will assign a new value to it prior to using it, so
whatever value it had up to that point would not be significant).
I think IE's behavior has been wrong the whole time.
Which behaviour specifically?
Variable instantiation should alter the value of the
window property.
Did you mean "should" there or 'should not'. The spec unambiguously says
'should not', and it is considered definitive when it comes to this type of
question.
Example:
<html>
<head>
<title></title>
</head>
<body onload="alert(out);">
^^^^^^^^^^^^^^^^^^
Very dubious. The functions that IE creates in response to intrinsic event
attribute declarations are quite aberrant in ECMAScript terms. They have
partly dynamically determined scope chain augmentations (that is, if you
move them form one element to another some, but not necessarily all, of the
scope chain reacts to their new context), they use a completely different
mechanism for determine their - this - value (such that such functions
originating in some contexts, if executed in isolation (not as methods of
any object) can even exhibit a - this - value that is not an object
reference (by definition an impossibility in ECMAScript). If you use this in
your analysis you risk drawing conclusions about one thing based upon an
artefact of another dubious system in IE.
For example, replace that event handler with -
onload="setTimeout('alert(out);', 1);" - and the alerted output will be
'[object]', so whichever object on the dynamically augmented scope chain of
the browser-created onload handler has an - out - property that had ended up
referring to the function object either it did not hang around for long, or
it was not the global object.
<div id='out'></div>
<pre>
<script type="text/javascript">
window.inn = 1;
var inn = 2;
document.write(out+'\n\n');
try {
this.out = function() {
};
} catch(ex) { alert( ex.message); }
document.write(out+'\n');
document.write(inn+'\n');
</script>
</pre>
</body>
</html>
Result (in IE):
[object]
[object]
2
alert => "function(){}"
Result in FF/Safari/Opera:
Don't fall victim of the delusion that something that happens in all of
these three browsers is therefor correct. Even if their behaviour is correct
is not correct by virtue of them all behaving the same.
[object HTMLDivElement]
function () {
}
2
But even if I remove the - var - from before the - out -
above and load the page into IE this second alert does
not output what you suggest; it never gets executed as
the preceding assignment throws an exception.
Right. The second write() does not execute because of
the error, so it's still "[object]".
As execution has stopped at that point is there meaning in assertions about
the nature of the values in the stopped system? In any event, it does not
actually take that many more words to turn an ambiguous comment at the end
of a line of code that will never be executed into a clear statement that
can be judged entirely on its own merits.
<script type="text/javascript">
document.write(out+'\n\n'); //undefined.
try {
function out() {
};
In ECMAScript terms this is a syntax error. A Block statement may one
contain a list of statements and no statement may commence with the
'function' keyword according to the language's syntax rules.
Here you are employing a syntax extension, or rather at least two different
syntax extensions. The specification explicitly allows for syntax
extensions, but they are of very little practical interest or use because no
two syntax extensions are likely to be identical so any attempt to use one
is very likely to have inconsistent, unpredictable and unreliable outcomes
(and that is assuming it does not come across an environment where no
equivalent syntax extension exists and the result is just a syntax error
being (more or less) reported and the script that contains it never being
executed).
} catch(ex) { alert( ex.message); }
document.write(out+'\n'); // function(){ ... }
</script>
IE:
function out() {
}
function out() {
}
FF:
[object HTMLDivElement]
function out() {
}
Your point being?
So IE and Fierfox have very different syntax extensions covering what
ECMAScript would regard as an out of context FunctionDeclaration? And as a
result the outcomes are different in those two environments. I notice that
you did not include Opera or Safari here.
A bottom script makes the page load faster.
The locations of SCRIPT elements within a document has no baring on the
presence or absence, or relative location of, global variable declarations.
Not very good at analyzing, huh?
Yes, not very good. Indeed in some respects you remind me of VK in that
regard (VK being the nadir of script analysis). For example, you have
published a page showing interactions with string objects (or rather the
objects resulting form type-converting string primitives into objects, which
may not be quite the same thing in some environments) where you describe
JScript behaving 100% in accordance with the language specification, and
then declare its behaviour to be incorrect. Then there was your recent
banning on about JScript's - propertyIsEnumerable - method being broken
without a single line of code that demonstrated anything of the kind, when
if it were true that should be the simplest thing in the world to
demonstrate. And then there was that time you wasted arguing that objects in
the DOM that implemented the NodeList and HTMLCollection interfaces were not
allowed to be function objects.
We'll see a test case here that I made not too long ago.
Will we see a clear statement bout what is being tested, and how the outcome
demonstrates the conclusions?
I don't have to know the details of browser bugs to know
that global variables can conflict with element ids.
So does everyone else, along with which reasonable steps can be taken to
avoid the issue.
That's not entirely true, IE allows:
window.out = function()
Maybe, but it is pretty closed for a quick summation of the situation.
When a reference error occurs in webkit:
<html>
<head><title>test element</title>
</head>
<body>
<input name="usevar" id="usevar"/>
<pre>
<script>
try
{
_referenceError();
Presumably it is the absence of any sort of definition for - _referenceError
- that provokes the throwing of an exception at this like of code,
preventing the evaluation of the assignment in the next line?
var usevar = 12;
}
catch (ieNeedsCatch)
{
}
finally {
document.write("usevar: " + usevar);
}
</script>
</pre>
</body>
</html>
usevar: [object HTMLInputElement]
Which is not exactly what you'd expect (undefined).
No, that is precisely what I would expect in an ECMA 262 conforming script
engine implementation running in a browser where named form controls were
being referred to by like-named properties of the global object. The spec
says that when variable instantiation acts on the variable declaration in -
var usevar = 12; - it must not alter the value of any pre-existing property
of the Variable object named 'usevar', the global object is the Variable
object in the global execution context, the - usevar - property it has
already has a value which refers to the form control's DOM element, and the
exception being thrown prevent the evaluation of the assignment to the -
usevar - variable. The observed outcome corresponds 100% with the expected
outcome in the environment in question.
So your point was? That is; what was this supposed to demonstrate, and how
did the outcome demonstrate it?
(Well that did not modify my opinion of your analytical abilities when it
comes to browser scripting).
So-
Menu = function() {
}
-
would be something you would have to avoid.
No of course not. Either the variable should be declared or the whole thing
should be a function declaration. The latter would be my choice here, as
there is a great deal to be said for doing the simple and obvious in scripts
whenever you have the choice.
Because it could be that theres'
<div id="Menu"></div>
on the page.
Which won't make one jot of difference to a FunctionDeclaration. Even the
question of modifying pre-existing properties of the Variable object does
not arise in the case of the FunctionDeclaration as they are supposed to
re-assign values to any pre-existing properties their names conflict with.
<snip>
[snip]
Pretty much, except that conceptually the thing being gotten
is an Interfaces not Objects.
Strategy/Adapter, huh?
What?
I use strategy in a different code style.
Just the one?
That's subject matter for another thread.
Link?
Advances search on google groups?
Avg 560 lines/file, which is not too unreasonable,
But not that representative given the range.
but building
javascript between QA phases? Why?
Because it is not uncommon for things to cycle back into development from
the fist QA phase, so there smaller, more desecrate, chunks have advantages.
(There is also the version control system to be contended with as if a bug
fix or an enhancement has a client-side script file attached to it that file
is locked out for any unrelated modification until QA have OKed it. If there
were only a few large files in the development environment it would be every
easy for them all to become locked out at once, and leave far too many
people sitting around twiddling their thumbs. (or, heaven forbid, catching
up with the documentation backlog ;-))
It is essential that the client-side code goes through full QA regression
testing following any global modification in its structure. As phase two is
regression testing of builds, between phase one and two is the last
opportunity to amalgamate the client-side code files.
Richard.