A "does global variable exist" function

[Ry Nohryb]

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

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

function doesGlobalVarExist (v) {
return v in function(){return this}() }

 

[Dmitry A. Soshnikov]

I really don't understand the worries about ES5 strict mode. Even
when ES5 is widely implemented, strict mode will be completely
optional.

Yeah, I think so. Moreover, as I mentioned, many programmers will
understand "strict mode" features incorrectly (I've heard even phrases
such as "we are not "children", but professionals, so use strict mode
only" -- not regarding ES, but in general -- HTML doctype, Perl, etc.).
Thus, presence of this feature is not related with the professionalism
in any respect. Using strict mode because it makes code more
professional -- is for laymen debates. And separating a language on
"strict" and "non-strict" will force those laymen make useless holywars.
Also, if to look on strict mode from the other side, it's about
inattentive, but not professional programmer -- a helper which warnings
such inattentive programmer if he uses e.g. `arguments' as a formal
parameter's name.

However, for "graceful degradation" -- for example, if the language
wants to remove some obsolete garbage, it's a good feature -- to mark
those deprecated stuff in strict mode (e.g. `with' statement, which
possible will be removed from newer versions; although, for me there
have never been problems with `with', but I used it rarely).

So from this position, `strict mode' is good. And possible someone (and
I think now someone, but about 90% of future ES programmers) will use
strict mode on the program level. And since the strictness inherits it
from the parent context, simple FD, FE will also be always strict. And
therefore, `function () {return this;}' will return `undefined'.

And a `Function' function may help to solve this issue -- since such
functions do not inherit strictness (it's needed to write "use strict"
directly in the body of the `Function' function).

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

})();

Yeah, agreed, that most of the discussed stuff is less about practical
cases. On practice, simple `var global = this;' or with `defineProperty'
is enough. Talks about shadowing etc. -- just theoretical things, which
can be interesting, but on practice we hardly will do this (I'm not
stupid to shadow `global' variable which I specially defined to get
global object with the local one `var global = 10' Who will do this?
Don't know.).

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

Academical theoretic discussions are also may be interesting (I am e.g.
ECMAScript theorist, besides my practical work, which currently isn't
even massively related with JS (but was many years of course) -- I
program on Erlang now and small part on JS). Knowing this stuff allows
to quickly answer practical questions/issues which many only-practical
programmers like to name "WTF(JS)?".

Dmitry.

 

[David Mark]

Yeah, I think so. Moreover, as I mentioned, many programmers will
understand "strict mode" features incorrectly (I've heard even phrases
such as "we are not "children", but professionals, so use strict mode
only" -- not regarding ES, but in general -- HTML doctype, Perl, etc.).

Most PERL programs would burn up under the strict microscope. CPAN is
the Dynamic Drive of the PERL world. As for doctypes, strict makes
sense unless you are actually transitioning from one type of markup to
another.

What is laughable is that for years the majority of new sites have
used the transitional XHTML doctype.

Why? Because the developers were sure they were supposed to be using
the "more advanced" (but dead) language, but didn't really understand
why. They likely aspired to validate their creations at some point,
but found strict validation too difficult, so settled for a
"transitional" period (that has lasted a decade for some). And, of
course, faced with the fact that IE did not support XHTML for the
first decade of the century, served it with an HTML MIME type, causing
browsers to error correct it back to HTML.

Or maybe the majority are simply propagating examples from the turn of
the century via their clipboards.

Thus, presence of this feature is not related with the professionalism
in any respect.

Certainly not. In fact, putting "use strict" at the top of s script
today implies the opposite. Same for using an HTML5 doctype. Rookies
always strive to use the "coolest" new technologies, even before their
end-users are ready for them.

Using strict mode because it makes code more
professional -- is for laymen debates.

Use JSLint, but know enough to interpret the results. End of story.
Great for catching typos too.

And separating a language on
"strict" and "non-strict" will force those laymen make useless holywars.

When it comes to JS, the average developer is so completely lost that
they won't likely look for ways to make browser scripting "harder".
Hell, most of the "major" libraries can't even get through JSLint, let
alone achieve respectable results.

Also, if to look on strict mode from the other side, it's about
inattentive, but not professional programmer -- a helper which warnings
such inattentive programmer if he uses e.g. `arguments' as a formal
parameter's name.

LOL. JSLint (or the like) would flag such nonsense. Of course, if a
developer is really that out of it, they've got bigger problems.

However, for "graceful degradation" -- for example, if the language
wants to remove some obsolete garbage, it's a good feature -- to mark
those deprecated stuff in strict mode (e.g. `with' statement, which
possible will be removed from newer versions; although, for me there
have never been problems with `with', but I used it rarely).

JSLint will almost certainly flag that too. Personally, in almost
fifteen years, I've never used a - with - clause.

So from this position, `strict mode' is good. And possible someone (and
I think now someone, but about 90% of future ES programmers) will use
strict mode on the program level.

Not sure how you arrived at that figure, but I definitely disagree.
More like 10%.

And since the strictness inherits it
from the parent context, simple FD, FE will also be always strict. And
therefore, `function () {return this;}' will return `undefined'.

So don't use it (in any context). ES5 is not yet widely implemented
anyway.

And a `Function' function may help to solve this issue -- since such
functions do not inherit strictness (it's needed to write "use strict"
directly in the body of the `Function' function).

A function created by calling the Function constructor? That's
usually avoided as bad form. In terms of style, it's no better than
eval.

Yeah, agreed, that most of the discussed stuff is less about practical
cases.

Yes, and some of it is downright dangerous.

On practice, simple `var global = this;' or with `defineProperty'
is enough.
Yes.

Talks about shadowing etc. -- just theoretical things, which
can be interesting, but on practice we hardly will do this (I'm not
stupid to shadow `global' variable which I specially defined to get
global object with the local one `var global = 10' Who will do this?
Don't know.).

Right. But there will always be those who waste time seeking the Holy
Grail solution to every problem, when in context a dixie cup would
suffice.

Academical theoretic discussions are also may be interesting (I am e.g.
ECMAScript theorist, besides my practical work, which currently isn't
even massively related with JS (but was many years of course) -- I
program on Erlang now and small part on JS). Knowing this stuff allows
to quickly answer practical questions/issues which many only-practical
programmers like to name "WTF(JS)?".

That's a familiar refrain (or at least demeanor). The sad truth is
that most people involved with or on the periphery of JS see it as a
vexing mystery. I suppose that programmers that are proficient with
"real" languages like Java, C++ or whatever, feel learning a "toy"
language like JS will be an easy career boost. Once they falter in
the most marketable application of JS (browser scripting), they start
to curse it as "broken" and look for libraries to bridge the gap (as
would be natural in other languages).

What they don't realize is that the authors of most libraries are
almost as confused as they are. They see how much trouble the library
authors are having, year-in and year-out and it makes them feel
better. At this point, the whole culture is based on programming for
failure and the language is an easy (but perfectly innocent)
scapegoat.

Some of them end up here and when told that they are confused, they
are very quick to rush back to the soothing tones of blogs and Web
forums populated by people suffering from the same mass hysteria.
Others actually learn and go straight to the top of the food chain.

 

[Asen Bozhilov]

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

})();

It's enough, but I would prefer:

(function (global /* = this */) {
// App goes here
})(this);

Regarding strict mode, I assume in the near future that will be the
new marketing trick of the most popular js libs. There will be:

"JQuery is compatible with ECMAScript 5 strict mode"

The strict mode is only helpful during development stage and for
beginner developers. The beginners can use these features for creating
good habits as JS developer. For people in this group I don't think
strict mode is something helpful. For example I use
`javascript.options.strict;true` in Firefox and in error console I get
warnings and errors for many thinks. e.g. undeclared
assignments.

 

[Scott Sauyet]

If you had bothered to take a closer look, you could have
discovered a review process, an official procedure for testing, a
dependency resolver, a bug tracker, namespace management, versioning,
format and naming conventions, tracking of module maintainers,
documentation, mailing lists, IRC channels, a usenet gateway, 100+
mirror sites, etc. Judging from your uninformed statement, I don't think
you've ever worked with CPAN before.

Yes, I'm overprotective about Perl

I think there's a support group...

 

[David Mark]

That's amusing, coming from someone who apparently isn't even familiar
enough with Perl to know how it's spelled.

That's how I "spell" it. Or at least how I spelled it in that
message.

And I am quite familiar with Perl and the general quality of freebie
Perl scripts found on the Web (particularly CPAN).

Are you aware that ES5's "use
strict" pragma was directly inspired by Perl?

How is that relevant?

And that almost all of the
modules on CPAN are running in strict mode?

Are they? Could I possibly have had the wrong site in mind (it's been
a few years). Regardless, strict mode does not good software
make.

I don't know why you felt it
necessary to compare CPAN to a collection of amateur scripts like
Dynamic Drive.

Because it is. I've had to work on lots of Perl applications that use
CPAN modules. Many of them were horrible (the apps and the modules).

If you had bothered to take a closer look, you could have
discovered a review process, an official procedure for testing, a
dependency resolver, a bug tracker, namespace management, versioning,
format and naming conventions, tracking of module maintainers,
documentation, mailing lists, IRC channels, a usenet gateway, 100+
mirror sites, etc.

I was referring only to the quality of the code contained therein (and
obviously not *all* of it). You can wrap up bad code in pretty bows,
but it's still bad code. Could be that the majority of it is better
than I remember, but not the bits I had to deal with. I'm
particularly reminded of several HTTP related scripts (and especially
an AIM interface).

Judging from your uninformed statement, I don't think
you've ever worked with CPAN before.

Obviously that's a false assumption.

Yes, I'm overprotective about Perl

Overprotective of PERL or the specific scripts on CPAN?

 

[David Mark]

Because Dmitry was talking about "strict mode" in ES5, and you replied
with your "strict microscope" quip, quoted above.
Okay.



Agreed. I will also gladly admit that there are a few bad apples in the
CPAN basket, but going by Sturgeon's Law ("ninety percent of everything
is crud"), I think CPAN is doing pretty well.

Yeah, don't get me wrong. The general quality of Perl scripts is far
higher than JS. So, CPAN is certainly a much better repository than
Dynamic Drive (if you can even call that site a repository). I was
just noting a parallel.

From what I've read, any software at all appears horrible to you (with
the possible exception of My Library).

Now that's a gross exaggeration. When have I written about anything
but freebie JS scripts? I think it goes without saying that virtually
of those are horrible (and I am hardly alone in that assessment).

Has anybody else ever written
code that meets your approval?

Of course.

Possibly. I retract that.

Fair enough. But change possibly to definitely.

Perl and CPAN as a whole. Individual modules may be out of date, or even
flat out ugly, but there's still a world of difference between CPAN and
a script kiddy site like Dynamic Drive.

Yes, they are similar in one way, but certainly not identical (or even
on the same playing field).