Testing to see if a variable exists...

[Ivan Marsh]

Hey Folks,

Anyone know how to test for the existance of a variable in javascript?

I'm looking for the equivalent of IsSet() from PHP. I'm having trouble
finding it.

thx

--
i.m.
The USA Patriot Act is the most unpatriotic act in American history.

[Yann-Erwan Perio]

Ivan Marsh wrote:

Anyone know how to test for the existance of a variable in javascript?

Check the 'typeof' operator:

<script type="text/javascript">
alert( typeof foo );
if(typeof foo == "undefined") {
// do stuff...
}
</script>

It's a good idea, when learning this property, to iterate over many
js/html types, in different user agents, to check the returned value.
You might be surprised sometimes (especially for "null" in js, and HTML
elements in Mozilla/IE).
HTH
Yep.

[Martin Honnen]

Ivan Marsh wrote:

Anyone know how to test for the existance of a variable in javascript?

I'm looking for the equivalent of IsSet() from PHP. I'm having trouble
finding it.

Not quite the same as isset in PHP but the JavaScript way is usually
if (typeof varname != 'undefined') {
// use varName
}
However that approach doesn't allow you to distinguish whether a
variable has not been declared or has been declared but not intialized,
that is if you declare
var varname;
then
typeof varname
is still 'undefined'. But that usually doesn't bother you as you only
want to check whether something useful is stored in the variable.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Michael Winter]

"Ivan Marsh" wrote on 11/11/2003:

Hey Folks,

Anyone know how to test for the existance of a variable in javascript?
I'm looking for the equivalent of IsSet() from PHP. I'm having trouble finding it.

Use this function:

function isSet( variable )
{
return( typeof( variable ) != 'undefined' );
}

It will work if a variable is defined, but not assigned to yet. For
example:

var a;
var b = 'used';

isSet( a ); // false
isSet( b ); // true

If you want to test for variables that have not been declared at all,
you have to test directly, or an error will occur. Continuing from
above:

if( typeof( c ) == 'undefined' )
{
// this will execute in this example
// c is not defined or has not been assigned to...
}
else
{
// c has been defined...
}

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

[Douglas Crockford]

> Anyone know how to test for the existance of a variable in javascript?

Runtime is not generally a good time to be checking that variables exist. It is
better to do it early with jslint. It produces a report that identifies
undeclared variables. It also reports declared but unused variables.

http://www.crockford.com/javascript/lint.html

[Richard Cornford]

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:Vd******************@news-text.cableinet.net...
<snip>

return( typeof( variable ) != 'undefined' );

<snip>

It is interesting that you have used parenthesise in the way you have in
the code above. They make typeof look like a function when it is an
operator that operates on an expression and return look like a function
call when it is a statement that may return an expression. That isn't
important for the execution of the code because JavaScript is very
tolerant of the presence (or absence) of white space, So:-

typeof(variable)

- is treated as if it was:-

typeof (variable)

- and - (variable) - is just a parenthesised expression. The parentheses
are serving no purpose so the effect is exactly the same as:-

typeof variable

While:-

return( ... );

- is treated as:-

return ( ... );

- and - ( ... ) - is another parenthesised expression, though in this
case parenthesising - typeof (variable ) != 'undefined' - would make it
clear that it is the result of evaluating the expression that is
returned and I would probably have done so myself (but I would have
placed a space before the "(").

No harmful consequences follow from the formulation of the original
code. Except possibly to blur the distinction between function calls and
the use of operators/statements, and maybe causing some confusion in the
minds of readers of the code.

Richard.

[Michael Winter]

"Richard Cornford" wrote 11/11/2003:

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message news:Vd******************@news-text.cableinet.net...
<snip>

return( typeof( variable ) != 'undefined' ); <snip>

It is interesting that you have used parenthesise in the way you

have in the code above. They make typeof look like a function when it is an
operator that operates on an expression and return look like a function call when it is a statement that may return an expression. That isn't important for the execution of the code because JavaScript is very
tolerant of the presence (or absence) of white space, So:-

typeof(variable)

- is treated as if it was:-

typeof (variable)

- and - (variable) - is just a parenthesised expression. The parentheses are serving no purpose so the effect is exactly the same as:-

typeof variable

While:-

return( ... );

- is treated as:-

return ( ... );

- and - ( ... ) - is another parenthesised expression, though in this case parenthesising - typeof (variable ) != 'undefined' - would make it clear that it is the result of evaluating the expression that is
returned and I would probably have done so myself (but I would have
placed a space before the "(").

No harmful consequences follow from the formulation of the original
code. Except possibly to blur the distinction between function calls and the use of operators/statements, and maybe causing some confusion in the minds of readers of the code.

I prefer to use parentheses wherever I can. I realise that typeof is
an operator, and is perfectly acceptable with, or without,
parentheses. I tend to surround all expressions and sub-expressions
with parentheses as I like not having to remember the operator
precedence table. I have enough to remember as it is, and not all
languages use the same precedence order. When I'm writing in C, C++
or Java, I even write return( true/false ), though I know it's not
necessary. It's part habit and part consistency.

Everyone has their own style, I suppose...

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

[Ivan Marsh]

On Tue, 11 Nov 2003 10:19:58 +0000, Douglas Crockford wrote:

Anyone know how to test for the existance of a variable in javascript?

Runtime is not generally a good time to be checking that variables
exist.

Yea, I know. What I was trying to do was get POST data easily into
JavaScript using PHP. Since the POST data isn't sent if the variable isn't
set I needed a way to check for unassigned variables. Instead I just
decided to add a default value if it's unassigned.

I originaly was doing:

print("<SCRIPT LANGUAGE='JavaScript'>\n");
foreach ($_POST as $key_var => $value_var) {
print("var " . $key_var . " = '" . $value_var . "';\n");
}
print("</SCRIPT>\n");

Which worked fine for everything that's posted. But if you try to use a
variable that wasn't assigned from post data it would crash that
javascript you were referencing it from.

This is what I ended up with:

function JSPostVar($postvar, $postvarval = "") {
print("<SCRIPT LANGUAGE='JavaScript'>\n");
if (IsSet($_POST[$postvar])) {
print("var " . $postvar . " = '" . $_POST[$postvar] . "';\n");
}
else {
print("var " . $postvar . " = '" . $postvarval . "';\n");
}
print("</SCRIPT>\n");
}

Maybe not as pretty as it could be but it serves its purpose.

--
i.m.
The USA Patriot Act is the most unpatriotic act in American history.

[Richard Cornford]

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:D5*******************@news-text.cableinet.net...
<snip>

I prefer to use parentheses wherever I can.
I bet that you wouldn't claim that if you stopped and thought about it
;-) Given how liberally you could insert parentheses into JavaScript
source code, especially as you can re-parenthesis any existing
parenthesised expression so inserting them "wherever you can" would
become recursive, you would be unlikely to ever manage to complete the
code for your first function.
I realise that typeof is an operator, and is perfectly
acceptable with, or without, parentheses. I tend to surround
all expressions and sub-expressions with parentheses as
I like not having to remember the operator precedence table.
I have enough to remember as it is, and not all languages use
the same precedence order. When I'm writing in C, C++ or Java,
I even write return( true/false ), though I know it's not
necessary. It's part habit and part consistency.
The parenthesising of (and within) expressions is not really the subject
of my quibble (and it is no more than that). I also do not bother to
memorise operator precedence in languages and instead use nested
parentheses to force (and express) my desired precedence (JavaScript's
automatic type conversion often makes that doubly desirable).

My comments were more aimed at the expression of the distinction between
a function call, in which the tradition is that the opening parenthesis
is not separated from the identifier or property accessor for the
function reference (even though it could be), and the nature of typeof
and void as operators and return as a statement. Which might be better
expressed by separating the expression from the operator/statement with
at least one space.

I mentioned it mostly because I often encounter people talking of "the
typeof function", "the void function" and (though very rarely) "the
return function". That is a misconception that could not easily arise
from reading the language documentation (or books on the subject) and I
suspect that it arises in the minds of authors new to JavaScript as a
result of seeing code that uses typeof (etc) in a function call-like
formulation.
Everyone has their own style, I suppose...

And so long as the resulting code executes nobody can stop you. But,
when posting in a group where some of the readers may reasonably be
expected to not be that experienced, would the cost of putting in the
odd extra space character to make code that represent function calls
distinct from code that is not a function call really be too much of an
inconvenience?

Richard.

[Michael Winter]

"Richard Cornford" wrote on 11/11/2003:

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message news:D5*******************@news-text.cableinet.net...
<snip>

I prefer to use parentheses wherever I can.
I bet that you wouldn't claim that if you stopped and thought about

it ;-) Given how liberally you could insert parentheses into JavaScript source code, especially as you can re-parenthesis any existing
parenthesised expression so inserting them "wherever you can" would
become recursive, you would be unlikely to ever manage to complete the code for your first function.
:p

I realise that typeof is an operator, and is perfectly
acceptable with, or without, parentheses. I tend to surround
all expressions and sub-expressions with parentheses as
I like not having to remember the operator precedence table.
I have enough to remember as it is, and not all languages use
the same precedence order. When I'm writing in C, C++ or Java,
I even write return( true/false ), though I know it's not
necessary. It's part habit and part consistency.

The parenthesising of (and within) expressions is not really the

subject of my quibble (and it is no more than that). I also do not bother to memorise operator precedence in languages and instead use nested
parentheses to force (and express) my desired precedence (JavaScript's automatic type conversion often makes that doubly desirable).

My comments were more aimed at the expression of the distinction between a function call, in which the tradition is that the opening parenthesis is not separated from the identifier or property accessor for the
function reference (even though it could be), and the nature of typeof and void as operators and return as a statement. Which might be better expressed by separating the expression from the operator/statement with at least one space.

I mentioned it mostly because I often encounter people talking of "the typeof function", "the void function" and (though very rarely) "the
return function". That is a misconception that could not easily arise from reading the language documentation (or books on the subject) and I suspect that it arises in the minds of authors new to JavaScript as a result of seeing code that uses typeof (etc) in a function call-like
formulation.

Everyone has their own style, I suppose...
And so long as the resulting code executes nobody can stop you. But,
when posting in a group where some of the readers may reasonably be
expected to not be that experienced, would the cost of putting in

the odd extra space character to make code that represent function calls
distinct from code that is not a function call really be too much of an inconvenience?

I see your point (I saw it the first time), and it's a good one. I'll
try to take it into consideration in future.

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

[Lasse Reichstein Nielsen]

"Ivan Marsh" <an*****@you.now> writes:

Yea, I know. What I was trying to do was get POST data easily into
JavaScript using PHP. Since the POST data isn't sent if the variable isn't
set I needed a way to check for unassigned variables. Instead I just
decided to add a default value if it's unassigned.

I originaly was doing:

print("<SCRIPT LANGUAGE='JavaScript'>\n");
foreach ($_POST as $key_var => $value_var) {
print("var " . $key_var . " = '" . $value_var . "';\n");
}
print("</SCRIPT>\n");

I recommend against adding variables dynamically, mostly because it
makes it harder to reason about the program.

If anything, I would make an object that is always created, and then
add the value as a property of that object. Javascript has methods for
checking whether a property is set, e.g.:
if ("propertyName" in objectRef) {...

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jim Ley]

On Tue, 11 Nov 2003 10:19:58 -0800, "Douglas Crockford"
<no****@laserlink.net> wrote:

Anyone know how to test for the existance of a variable in javascript?

Runtime is not generally a good time to be checking that variables exist. It is
better to do it early with jslint. It produces a report that identifies
undeclared variables. It also reports declared but unused variables.

Except of course that in an unknown execution environment where your
code can be modified before it's executed, runtime is the only time
you can ensure that it's been declared, any time earlier you're only
checking that the code you wrote - if it runs declares it, that's a
very different thing.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Thomas 'PointedEars' Lahn]

Yann-Erwan Perio wrote:

Ivan Marsh wrote:

Anyone know how to test for the existance of a variable in javascript?

Check the 'typeof' operator:

<script type="text/javascript">
alert( typeof foo );
if(typeof foo == "undefined") {
// do stuff...
}

Although there may be rare occasions where the above is useful, it is
better to "do stuff" if `foo' is _not_ undefined (i.e. typeof foo !=
"undefined"). The gauntlet usually *prevents* access to undefined
variables, objects and properties.
PointedEars