Loading ...
Sorry, an error occurred while loading the content.

Re: option.browser

Expand Messages
  • pauanyu
    ... I am curious, why is: if (typeof foo === undefined ) { better than: if (!foo) { ?
    Message 1 of 8 , May 4, 2009
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
      >
      > When feature testing, it is recommended that you use
      >
      > if (typeof console === 'object') {
      >
      > instead of
      >
      > if (window.console) {
      >

      I am curious, why is:
      if (typeof foo === 'undefined') {

      better than:
      if (!foo) {

      ?
    • crlender
      ... In your example, if foo is not declared, it will result in a ReferenceError being thrown. This won t happen if you test with the typeof operator. I think
      Message 2 of 8 , May 4, 2009
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
        > I am curious, why is:
        > if (typeof foo === 'undefined') {
        >
        > better than:
        > if (!foo) {

        In your example, if foo is not declared, it will result in a
        ReferenceError being thrown. This won't happen if you test with the
        typeof operator. I think DC's point was about avoiding the reference
        to 'window' when testing for a global variable, since 'window' is no
        longer part of option.browser.

        In addition to that, '!foo' converts a value to boolean, and some
        host objects (especially in IE) are known to throw exceptions if
        you try that. typeof is always safe*.

        - Conrad


        * Except, I think, in one weird Safari 2 bug when items of a
        NodeList are checked, but I'd have to look that up.
      • pauanyu
        ... I see; thank you. Another question, why use: if (typeof console === object ) { Instead of: if (console instanceof Object) { ? As far as I know, if
        Message 3 of 8 , May 5, 2009
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
          >
          > In your example, if foo is not declared, it will result in a
          > ReferenceError being thrown. This won't happen if you test with the
          > typeof operator. I think DC's point was about avoiding the reference
          > to 'window' when testing for a global variable, since 'window' is no
          > longer part of option.browser.
          >
          > In addition to that, '!foo' converts a value to boolean, and some
          > host objects (especially in IE) are known to throw exceptions if
          > you try that. typeof is always safe*.
          >
          > - Conrad
          >
          >
          > * Except, I think, in one weird Safari 2 bug when items of a
          > NodeList are checked, but I'd have to look that up.
          >

          I see; thank you. Another question, why use:
          if (typeof console === 'object') {

          Instead of:
          if (console instanceof Object) {

          ?

          As far as I know, if "console" is null, typeof will return 'object', which would break the first code.

          P.S. I know what the point of Douglas' post is, but he brought up the idea of using typeof, and I was curious why he recommended it, rather than an alternative.
        • Marcel Duran
          ... typeof will always return a string result, hence you have a guarantee you ll get something to test against, on the other hand when testing with: if
          Message 4 of 8 , May 8, 2009
          • 0 Attachment
            On Tue, May 5, 2009 at 9:47 AM, pauanyu <pcxunlimited@...> wrote:

            > I see; thank you. Another question, why use:
            > if (typeof console === 'object') {
            >
            > Instead of:
            > if (console instanceof Object) {
            >
            > ?
            >
            > As far as I know, if "console" is null, typeof will return 'object', which
            > would break the first code.
            >
            >



            typeof will always return a string result, hence you have a guarantee you'll
            get something to test against, on the other hand when testing with:

            if (console instanceof Object) {

            if console isn't declared you'll get a ReferenceError when trying to use
            instanceof. You likely won't have problems on firefox w/ firebug which has
            the console declared.


            --
            Marcel Duran


            [Non-text portions of this message have been removed]
          • douglascrockford
            The browser predefinition list has gotten a lot shorter: /*global clearInterval: false, clearTimeout: false, document: false, event: false, frames: false,
            Message 5 of 8 , Feb 11, 2011
            • 0 Attachment
              The browser predefinition list has gotten a lot shorter:

              /*global clearInterval: false, clearTimeout: false,
              document: false, event: false, frames: false,
              history: false, Image: false, location: false,
              name: false, navigator: false, Option: false,
              parent: false, screen: false, setInterval: false,
              setTimeout: false, XMLHttpRequest: false */

              The window.* methods and related properties have been removed.
              It is generally a bad idea to be poking at the window object,
              but if you must, do it explicitly. Write

              window.addEventListener(...)

              and not

              addEventListener(...)

              because the implicit form fails in strict mode. When a function is called as a function, this will be bound to undefined. In sloppy mode, this was bound to the global object, which was a bad idea, which enabled the implicit form, which was also a bad idea.
            • Rob Richardson
              I see setTimeout (and cousins) are still in the browser defined list, but would you recomend the same rule of thumb be true for these? E.g. would you
              Message 6 of 8 , Feb 11, 2011
              • 0 Attachment
                I see setTimeout (and cousins) are still in the browser defined list, but
                would you recomend the same rule of thumb be true for these? E.g. would you
                recommend "window.setTimeout( func...." rather than "setTimeout( func...."?

                Rob


                -----Original Message-----
                From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
                Behalf Of douglascrockford
                Sent: Friday, February 11, 2011 8:17 AM
                To: jslint_com@yahoogroups.com
                Subject: [jslint] option.browser

                The browser predefinition list has gotten a lot shorter:

                /*global clearInterval: false, clearTimeout: false,
                document: false, event: false, frames: false,
                history: false, Image: false, location: false,
                name: false, navigator: false, Option: false,
                parent: false, screen: false, setInterval: false,
                setTimeout: false, XMLHttpRequest: false */

                The window.* methods and related properties have been removed.
                It is generally a bad idea to be poking at the window object,
                but if you must, do it explicitly. Write

                window.addEventListener(...)

                and not

                addEventListener(...)

                because the implicit form fails in strict mode. When a function is called as
                a function, this will be bound to undefined. In sloppy mode, this was bound
                to the global object, which was a bad idea, which enabled the implicit form,
                which was also a bad idea.
              • Douglas Crockford
                ... They are global functions, not methods of the window object, so they work correctly without the window. prefix.
                Message 7 of 8 , Feb 11, 2011
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
                  >
                  > I see setTimeout (and cousins) are still in the browser defined list, but
                  > would you recomend the same rule of thumb be true for these? E.g. would you
                  > recommend "window.setTimeout( func...." rather than "setTimeout( func...."?


                  They are global functions, not methods of the window object, so they work correctly without the window. prefix.
                Your message has been successfully submitted and would be delivered to recipients shortly.