From: Sean Kinsey on
On Jul 29, 12:07 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
....
> 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.
> --
> Jorge.

In that case the only option is
if ((new Function('return "nameOfVar" in this;'))()) {
// nameOfVar exists in the global scope
}
From: David Mark on
On Jul 29, 5:58 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> On Jul 29, 11:45 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > On Jul 29, 5:35 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
>
> > > On Jul 29, 11:22 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > > > 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.
>
> > 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)

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!
From: Andrea Giammarchi on
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
From: David Mark on
On Jul 29, 7:34 am, Andrea Giammarchi <andrea.giammar...(a)gmail.com>
wrote:
> 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!
From: David Mark on
On Jul 28, 10:51 pm, RobG <rg...(a)iinet.net.au> wrote:
> 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).