A "does global variable exist" function
in [JavaScript]
|
Prev: FAQ Topic - Why does simple decimal arithmetic give strange results? (2010-07-29)
Next: validate 3 fields
From: Ry Nohryb on 29 Jul 2010 18:42 On Jul 29, 6:42 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> 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; > } function doesGlobalVarExist (v) { return v in function(){return this}() } -- Jorge.
From: Asen Bozhilov on 30 Jul 2010 08:14 David Mark wrote: > 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.
From: Stefan Weiss on 30 Jul 2010 08:33 On 30/07/10 13:41, David Mark wrote: > On Jul 30, 5:03 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> > wrote: >> On 30.07.2010 2:23, David Mark wrote: >> > 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.). > > Most PERL programs would burn up under the strict microscope. CPAN is > the Dynamic Drive of the PERL world. That's amusing, coming from someone who apparently isn't even familiar enough with Perl to know how it's spelled. Are you aware that ES5's "use strict" pragma was directly inspired by Perl? And that almost all of the modules on CPAN are running in strict mode? I don't know why you felt it necessary to compare CPAN to a collection of amateur scripts like Dynamic Drive. 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 :) -- stefan
From: Scott Sauyet on 30 Jul 2010 12:56 Stefan Weiss wrote: > 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... :-) -- Scott
From: David Mark on 30 Jul 2010 16:22
On Jul 30, 8:33 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > On 30/07/10 13:41, David Mark wrote: > > > On Jul 30, 5:03 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> > > wrote: > >> On 30.07.2010 2:23, David Mark wrote: > >> > 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.).. > > > Most PERL programs would burn up under the strict microscope. CPAN is > > the Dynamic Drive of the PERL world. > > 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? |