A "does global variable exist" function

[David Mark]

Are you leaving ?

Soon enough; but age before beauty...

I mean, haven't you done enough here?

 

[Ry Nohryb]

I expected better from you, El Abuelo.  Every time I give you the
slightest shred of credit, you make me regret it.

We don't have to agree, Mark, so don't worry.

I saw the "This section is not normative." in bold in there. But,
there's so many that aren't normative -yet- in the browsers...

http://google.com/search?q="This+section+is+not+normative"site=w3.org
--> About 416 results

Say, e.g. the timers, the navigator object, the XHRs... don't you use
them ? Well, you shouldn't: they're not in any standard! (maybe
they've been finally standardized recently (?)).

 

[David Mark]

We don't have to agree, Mark, so don't worry.

Worry about what?

I saw the "This section is not normative." in bold in there. But,
there's so many that aren't normative -yet- in the browsers...

The section it refers to in the *language specification* is not
normative either.

http://google.com/search?q="This+section+is+not+normative"site=w3.org
--> About 416 results
And?


Say, e.g. the timers, the navigator object, the XHRs... don't you use
them ?

For one, you are looking at the wrong specifications as we are
discussing language features. For two, there is no standard DOM
specification for the window object anyway.

Well, you shouldn't: they're not in any standard! (maybe
they've been finally standardized recently (?)).

You don't get it. Don't use something that has no formal
specification if there is a standard alternative. And certainly don't
make assumptions about host objects when you don't have to.

 

[Ry Nohryb]

Worry about what?




The section it refers to in the *language specification* is not
normative either.




For one, you are looking at the wrong specifications as we are
discussing language features.  For two, there is no standard DOM
specification for the window object anyway.


You don't get it.  Don't use something that has no formal
specification if there is a standard alternative.  And certainly don't
make assumptions about host objects when you don't have to.  

Since when is the Global Object a host object?

 

[Ry Nohryb]

For one, you are looking at the wrong specifications as we are
discussing language features.

The Global Object is a language feature, the 'window' symbol is not.

 

[David Mark]

The Global Object is a language feature, the 'window' symbol is not.

Yes, exactly. And you brought it into the discussion where it had no
place.

 

[David Mark]

Since when is the Global Object a host object?

Since never, Jorge. Are you trying to be funny?

 

[Sean Kinsey]

I stumbled across a function that tests if a global variable exists or
not, my version of the code is below. Other than the obvious
irrelevance of such a function (a simple typeof test should be
sufficient in every case I can imagine), and that the use of
try..catch and eval should be limited as much as possible, are there
any significant issues with it?

  function doesGlobalVarExist(v) {

      try {
          eval(v);
          return true;

      } catch(e) {
          return false;
      }
  }

Isn't the biggest problem with this (and any eval-like solution) that
it isn't without side effects?
What if the variable you are checking contains executable code?
var foo = 'alert("foo")';
doesGlobalVarExist(foo); // alerts foo;


And if the only goal here is to test if a variable has a value, then
typeof is the proper way to go as both null and undefined will eval
just fine and result in true being returned from the above function.

 

[Ry Nohryb]

Yes, exactly.  And you brought it into the discussion where it had no
place.  

The w3 site is the right place to show you where to read that the
'window' symbol (not a language feature) that you believe to be a host
object (it's the object that implements the Window interface) is in
fact ("for some languages, such as ECMAScript") the Global Object
("the object that provides the global namespace for script
execution"), which is not a host object -but you seem to believe it
is-.

Now, next, come and tell me that it is in IEs, so that I can ROTFLOL.

 

[Ry Nohryb]

Isn't the biggest problem with this (and any eval-like solution) that
it isn't without side effects?

What if the variable you are checking contains executable code?
    var foo = 'alert("foo")';
    doesGlobalVarExist(foo); // alerts foo;
True.

And if the only goal here is to test if a variable has a value, then
typeof is the proper way to go (...)

ISTM that typeof does not reveal "has a value" properly because a var
that exists might hold the value undefined, and typeof would return
undefined too for a var that does not exist. As the topic of this
thread is "does global variable exist", I'd say that typeof is not the
proper solution.

 

[Sean Kinsey]

ISTM that typeof does not reveal "has a value" properly because a var
that exists might hold the value undefined, and typeof would return
undefined too for a var that does not exist. As the topic of this
thread is "does global variable exist", I'd say that typeof is not the
proper solution.

In that case the only option is
if ((new Function('return "nameOfVar" in this;'))()) {
// nameOfVar exists in the global scope
}

 

[David Mark]

The w3 site is the right place to show you where to read that the
'window' symbol (not a language feature)

You are going in circles Jorge. As I mentioned (right above) the
window object had no place in the discussion in the first place.

that you believe to be a host
object (it's the object that implements the Window interface)

Of course it is a host object. It's sure as hell not a language
feature (as you yourself just noted).

is in
fact ("for some languages, such as ECMAScript") the Global Object
("the object that provides the global namespace for script
execution"), which is not a host object -but you seem to believe it
is-.

Again, round and round in circles. We just had this discussion.
Again, you are quoting from something that is far removed from being a
standard (and that is certainly not part of the language
specification).

Now, next, come and tell me that it is in IEs, so that I can ROTFLOL.

I'll tell you no such thing. Nobody could say definitively what it is
in IE, except the IE developers. Thing is, you shouldn't need to
wonder about it.

Get better Jorge!

 

[Andrea Giammarchi]

as usual, David Mark did not get anything, did he?

I already wrote about the typo, the concept is clear.

Tell e which browser does not support that insertBefore, thanks.

script = null is pointless but specially with DOM nodes and IE around
I always prefer to nullify pointers and since it does not hurt,
pointless comment from your side.

new Function is pointless as well, new before Function is a
misconception of the Function itself

the Function suggestion is bad in any case, and the eval ...

(new Function("p", "return eval(p)"))("p")
// "p", FAIL!


var arguments = 123;
(new Function("p", "return eval(p)"))("arguments");
// [object Arguments], FAIL!

You are always blind man, you rush too much with your bossy blaming
and you keep doing mistakes ( who doesn't, but no reason to pick over
everything and obvious things, this does not make you a better
developer ... just annoying one that keeps doing mistakes ... )

Once again:

// compatible ES5 and "use strict"
var isGlobal = function (what) {
function $isGlobal(what) {
return what in context;
}
var
script = document.createElement("script"),
context = document.documentElement
;
script.text = "this._isGlobal=this;";
context.insertBefore(script, context.firstChild);
context.removeChild(script);
script = null; // comment out if it hurts ...
context = _isGlobal;
delete context._isGlobal;
context.isGlobal = (isGlobal = $isGlobal);
return isGlobal(what);
};

Regards,
Andrea Giammarchi

 

[David Mark]

as usual, David Mark did not get anything, did he?

And Andrea Giammarchi still doesn't know how to quote on Usenet, so
his posts have no context at all.

And no, in all of the years you have been posting here, due to your
quoting problems and a palpable language barrier (prose and code),
I've never "gotten" a single thing from you.

I already wrote about the typo, the concept is clear.

Nobody ever knows what you are writing about. See above. And there's
nothing clear about your code.

Tell e which browser does not support that insertBefore, thanks.

Show you where it fails? Can you see every browser, every rendering
and parse mode, past, present and future? Assuming no, why would you
do something so obviously hinged on your observations when there are
any number of reasonable alternatives that are based on the standards
referenced by browser developers?

script = null is pointless but specially with DOM nodes and IE around
I always prefer to nullify pointers and since it does not hurt,
pointless comment from your side.

It simply wastes space and obscures your intentions. For all I knew,
you pasted that in at random.

new Function is pointless as well, new before Function is a
misconception of the Function itself

What are you talking about? I find myself saying that a lot when
"discussing" browser scripting with you.

the Function suggestion is bad in any case, and the eval ...

I didn't suggest anything to do with eval. Quite the contrary, I said
not to use it at all.

(new Function("p", "return eval(p)"))("p")
// "p", FAIL!

Not only did I point that out previously, but I gave the solution.

var arguments = 123;
(new Function("p", "return eval(p)"))("arguments");
// [object Arguments], FAIL!

I didn't write anything like that (and certainly never would). And
please stop shouting.

You are always blind man, you rush too much with your bossy blaming
and you keep doing mistakes ( who doesn't, but no reason to pick over
everything and obvious things, this does not make you a better
developer ... just annoying one that keeps doing mistakes ... )

You are beyond belief. You write bad code followed by "FAIL!" and
then call me a blind man. What does any of this mean? And again, I
often find myself asking you such questions.

Once again:

[snip junk code]

No thanks!

 

[David Mark]

I stumbled across a function that tests if a global variable exists or
not, my version of the code is below. Other than the obvious
irrelevance of such a function (a simple typeof test should be
sufficient in every case I can imagine), and that the use of
try..catch and eval should be limited as much as possible, are there
any significant issues with it?

  function doesGlobalVarExist(v) {

      try {
          eval(v);
          return true;

      } catch(e) {
          return false;
      }
  }

Given the description of the eval function in ECMA-262 ed 3 (ES 3) §
15.1.2.1 and eval code in § 10.1.2, it seems that when using a
"namespace" with functions initialised from an anonymous function it
is impossible to use eval to run code with global scope, e.g.:

As there seems to be some confusion down the line, I should point out
that this question is not asking for a script injection solution
(which I'm sure we both know is the only way to run code in the global
context), but a way to use eval (or its alias the Function
constructor) in a nested local scope without pollution from the
containing scope.

As a (bogus) script injection solution has been introduced in
response, I recommend looking at the feature testing bit of the
addScript function in My Library as it could be modified to solve this
(purely academic) problem. In fact, the injected "solution"
introduced looks suspiciously like a broken imitation of it (or of
some of Randy Webb's old work).

 

[Ry Nohryb]

You are going in circles Jorge.  As I mentioned (right above) the
window object had no place in the discussion in the first place.


Of course it is a host object.  It's sure as hell not a language
feature (as you yourself just noted).

As Pointy would put it: Non sequitur.

The Window interface is implemented on the Global Object, not on a
host object. HTH.

 

[Ry Nohryb]

In that case the only option is
  if ((new Function('return "nameOfVar" in this;'))()) {
     // nameOfVar exists in the global scope
  }

Nice.

function doesGlobalVarExist (varName) {
return Function('return "'+ varName+ '" in this')();
}

 

[Lasse Reichstein Nielsen]

I stumbled across a function that tests if a global variable exists or
not, my version of the code is below. Other than the obvious
irrelevance of such a function (a simple typeof test should be
sufficient in every case I can imagine), and that the use of
try..catch and eval should be limited as much as possible, are there
any significant issues with it?

Others have pointed out a lot of shortcommings.
Generally, you have a problem with function parameters shadowing what
you can see through the scope chain (e.g. try checking if "arguments"
is a property of the global object?)

To avoid that, don't use eval (the non-direct call to eval isn't
in all browsers yet, and eval has side effects). Ok, generally,
don't use eval. Using eval is a sign that you are doing something
wrong[1].

Passing the name of a variable around as a string is also a sign that
you are doing something wrong - you are working at two different levels
at the same time.

In any case, just check for the property on the global object:

function doesGlobalVarExist(v) {
var global = function(){return this;}();
return v in global;
}

(It probablt doesn't work safe in strict mode ES5)

/L

 

[Dmitry A. Soshnikov]

On 29.07.2010 20:42, Lasse Reichstein Nielsen wrote:

In any case, just check for the property on the global object:

function doesGlobalVarExist(v) {
var global = function(){return this;}();
return v in global;
}

(It probablt doesn't work safe in strict mode ES5)

Yes, it doesn't work in strict mode ES5, and not probably but exactly
(because `global' is `undefined' in this case ). You can read "Strict
Mode" article mentioned by me in this thread earlier if you want. There
all these cases are discussed.

And only indirect `eval' call may help to get global `this' value.

Dmitry.

 

[David Mark]

On 29.07.2010 20:42, Lasse Reichstein Nielsen wrote:

<snip>






Yes, it doesn't work in strict mode ES5, and not probably but exactly
(because `global' is `undefined' in this case ). You can read "Strict
Mode" article mentioned by me in this thread earlier if you want. There
all these cases are discussed.

And only indirect `eval' call may help to get global `this' value.

I really don't understand the worries about ES5 strict mode. Even
when ES5 is widely implemented, strict mode will be completely
optional. That being said, in production code, this is the best
solution (and will work in anything new enough to support the - in -
operator, which is virtually everything in use today):-

var global = this;

(function() {

function isGlobal(s) {
return s in global;
}

// App goes here

})();

Everything else discussed in this thread was academic (and some of it
really awful).