Janak Ramakrishnan

Hi Mark, I'd like to thank you for having documentation online, and I
think your point that Firefox doesn't warn when a global variable is
overwritten by a local one is valid, and a good point.  However, your
example of Firefox warning when it shouldn't is, I think, not correct.
 Firefox warns when you write
if( document.body.childNodes[10] == e.target ) {
but it's not because childNodes may not be defined -- it's because if
childNodes doesn't exist, you can't do childNodes[10].  That is a
perfectly reasonable warning, and one that I would expect.  You also
say that it would warn if onclick weren't defined and you had this
code:
if( document.onclick == myFunction ) {
That is not correct -- Firefox will not warn then.  Firefox will only
warn if you try to take a property of a non-object.  To stop the
warning in the first case, you could write:
if (document.body.childNodes && document.body.childNodes[10] == e.target) {
which is good programming practice.  While you may be correct that
this warning dissuades people from doing cross-browser testing, the
solution is to add the additional test that the property exists in the
first place, before you test the value of the property.

Best,
Janak

Sorry, you're quite right, I misunderstood your criticism.  But I
agree that, while Firefox might reasonably loosen their warning
system, it's good practice to do
if (foo.bar && foo.bar == 'baz')
or, with the tradeoff of specificity versus length (or if you're
testing for a property with value 0, etc.),
if (typeof(foo.bar) != 'undefined' && foo.bar == 0)

I think it's good practice because most other programming languages
have a mode where they warn about such undefined properties, and also,
in some very real sense, your first test should be if the property is
defined -- that is already a browser-capability test.

Best,
Janak

Hi Tarquin, I think that this is an issue that we'll have disagree on.
 Other loosely typed scripting languages (like PHP and Perl) have the
option to turn on "strict" warnings.  PHP will issue a "notice" if you
use an undefined variable.  Perl will error out on uninitialized
variables if you say
use strict;
at the beginning of your script.  I understand what you're saying --
that in some cases, you are testing for the presence of a property in
the first place.  However, that is the case in PHP as well -- in the
$_REQUEST array, there may or may not be various attributes.  PHP
throws up a notice if you access a nonexistent attribute.

I think that accessing an undefined attribute for the purpose of
testing its value is different from accessing it for the purposes of,
say, assigning it to another variable, and, in a more intelligent
scripting world, the two might generate different levels of errors.
But as it stands, I think that Mozilla is in the mainstream in warning
about undefineds, and pleading special circumstances for Javascript is
not very convincing to me.  There are lots of scripting languages, and
they all need to run quickly, and there is a way around this warning
in Javascript, as I (and all the other posters -- I see how many times
you've dealt with this issue) have said.

Janak

Hi Tarquin,

> objects and properties, but they are an afterthought) and in PHP, using
> an uninitialised variable is extremely dangerous since it can be
> populated using the query string and used for cross site scripting

This doesn't make sense -- if the variable has been automatically
populated (using register_globals), then PHP won't warn, AFAIK.  As a
side note, enabling register_globals is insane.  This warning is also
there in Perl, and in every other decent language that I know of that
allows undeclared variables.

>> But as it stands, I think that Mozilla is in the mainstream in warning
>> about undefineds
>
> It fails to warn about real problems (overwriting variables in the

I noted my appreciation for your page in my first email -- I think
that your other criticisms of Mozilla's debugging are quite valid.

> yourself included, to write scripts that perform twice as slowly as a
> properly written script. All for the purpose of satisfying a stupid

This is a deceptively-phrased statement.  While testing for existence
and then value may, as you say, be twice as slow as just testing for
value, most scripts do more than that.  I sincerely doubt that any
real script has this test as a bottleneck -- testing for existence
should only ever be done once for a given property.

[Ed. Note that in a loop, this condition could be checked hundreds of
thousands of times, and would indeed become a bottleneck. This does
happen in real-World cases.]

I understand your criticism, and your request for ease-of-use for
Javascript, but there are certain programming conventions that are
fairly universal.  Not using goto's, for instance.  If you had an
example of another language where testing an uninitialized value was
always ok, I would be more inclined to agree with you.  But
Javascript's origins are so messy, if it breaks a rule that all other
languages follow, I am not going to think that Javascript is in the
right.

[Ed. Note that JavaScript is not breaking any rules here. Firstly it is
its own language, not another language, and can do whatever makes sense in
JavaScript, even if that is not the same as other languages. Secondly, many
other loosely-typed languages allow the exact same construct, and testing
of an undefined property against a defined value.]

Janak