Testing to see if a variable exists...

I

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
 
Y

Yann-Erwan Perio

Ivan said:
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.
 
M

Martin Honnen

Ivan said:
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.
 
M

Michael Winter

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
 
D

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
 
R

Richard Cornford

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.
 
M

Michael Winter

11/11/2003:
<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
 
I

Ivan Marsh

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.
 
R

Richard Cornford

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.
 
M

Michael Winter

on 11/11/2003:
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


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.


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
 
L

Lasse Reichstein Nielsen

Ivan Marsh said:
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
 
J

Jim Ley

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.
 
T

Thomas 'PointedEars' Lahn

Yann-Erwan Perio said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top