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

RE: [jslint] Re: console read only

Expand Messages
  • Alexandre Morgaut
    ... Firefox. If the ECMA standard is in disagreement with me then Firefox s interpretation of JavaScript is nonstandard or the standard is wrong. Wow ! Be
    Message 1 of 18 , Jul 9, 2009
    • 0 Attachment
      >Here is how to test what I have claimed:

      >xyzpdq === undefined //true
      >typeof(xyzpdq) === 'undefined' //true
      >typeof(undefined) === 'undefined' //true
      >typeof(typeof(undefined)) === 'string' //true
      >typeof(String) === 'function' //true
      >typeof(typeof(String)) === 'string' //true

      >I know that this is accurate, because this is how JavaScript evaluates in
      Firefox. If the ECMA standard is in disagreement with me >then Firefox's
      interpretation of JavaScript is nonstandard or the standard is wrong.

      Wow !

      Be carrefull with what you're testing.

      >xyzpdq === undefined //true

      Yes if xyzpdq is undefined AND is declared by "var" or is a property of a
      parent object
      otherwise, the exception is thrown



      >typeof(xyzpdq) === 'undefined' //true
      >typeof(undefined) === 'undefined' //true

      typeof return the name of the type of a variable, so yes the result is
      received as a string
      This doesn't mean that the value of the variable is a string
      the "advantage" of using typeof is that you will have a 'undefined' result
      if the tested variable has never been declared or assigned (which if not
      declared would have created it as a property of the global object which is
      window in browser)
      By the way, typeof is not a function but an unary operator (like "delete"
      and "void"), so even if JavaScript engines accept this notation it should be
      called like this :

      typeof undefined === 'undefined'

      and if you want to be more readable and conform to a frequently used good
      practice you could write it as :

      'undefined' === typeof undefined



      >typeof(typeof(undefined)) === 'string' //true
      >typeof(typeof(String)) === 'string' //true

      This will be true for every result of typeof so :

      var myArray = [];
      typeof(typeof(myArray)) === 'string' //true




      >typeof(String) === 'function' //true

      String is the constructor of string objects, so yes it is a function





      [Non-text portions of this message have been removed]
    • crlender
      ... They re not. ... They don t. ... types were objects, typeof would return object for each of them, and would be quite useless. typeof --
      Message 2 of 18 , Jul 9, 2009
      • 0 Attachment
        "sandyhead25" <austin.cheney@...> wrote:
        > Unary operators are typically regarded as poor practice in
        > JavaScript

        They're not.

        > and still require use of a name variable.

        They don't.

        > > No. There is no "JavaScript undefined object". |undefined| is a
        > > primitive value.
        >
        > We were both wrong. undefined is an object property. All other
        > types are, however, objects.

        |undefined| is not an object property, it's a primitive value. If all
        types were objects, typeof would return "object" for each of them,
        and would be quite useless.

        typeof "" --> "string"
        typeof new String("") --> "object"

        What you probably meant to say is that for most types, there exists
        a built-in constructor with a similar name:

        "object" --> Object
        "number" --> Number
        "string" --> String
        "boolean" --> Boolean
        "function" --> Function

        "undefined" --> no constructor
        "unknown" --> no constructor (used by IE)
        "other-host-defined-type" --> depends on host environment

        > > No, because as mentioned above there is no "undefined object",
        > > and the *value* of |undefined| has nothing to do with strings.
        >
        > If the value of undefined is of type string then it has everything
        > to do with the String object.

        The value of |undefined| can never be a string. Its value is
        |undefined|, and its type is "undefined".

        > The root of your confusion seems vested in collusion of value and
        > type, which are not related except for type Number. String object
        > is a perfect example of this because the object's name is String
        > with a capital 'S', but the type represented by that object is
        > 'string' with a lowercase 's'.

        Here's a String object: new String("hey").
        It doesn't have a name. It has a constructor (String), and it has a
        type ("object").

        > If a variable is not defined you cannot test for any type other
        > than undefined,

        Sure I can:
        var foo;
        if (typeof foo == "object") { ... }

        Doesn't make a lot of sense this way, but it could happen if the
        variable foo were declared somewhere else (not your code), and you
        don't know if it's currently defined or not.

        > which implies that types for values passed into
        > that variable cannot be tested.

        I don't understand what you mean by that.

        > Here is how to test what I have claimed:
        >
        > xyzpdq === undefined //true
        > typeof(xyzpdq) === 'undefined' //true
        > typeof(undefined) === 'undefined' //true
        > typeof(typeof(undefined)) === 'string' //true
        > typeof(String) === 'function' //true
        > typeof(typeof(String)) === 'string' //true
        >
        > I know that this is accurate, because this is how JavaScript
        > evaluates in Firefox. If the ECMA standard is in disagreement with
        > me then Firefox's interpretation of JavaScript is nonstandard or
        > the standard is wrong.

        By definition, the specification can't be wrong (except for errata,
        which are also available for download). Testing the type of
        |typeof|'s return value doesn't make sense, because typeof will
        always return a string. Your first example is dangerous and will blow
        up with a ReferenceError if xyzpdq can not be resolved along the scope
        chain.


        - Conrad
      • sandyhead25
        ... They why are unary operators frowned upon by the jslint tool? ... Operators require something to act upon. ... Functions are objects. Types are derived
        Message 3 of 18 , Jul 9, 2009
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
          >
          > "sandyhead25" <austin.cheney@> wrote:
          > > Unary operators are typically regarded as poor practice in
          > > JavaScript
          >
          > They're not.

          They why are unary operators frowned upon by the jslint tool?

          > > and still require use of a name variable.
          >
          > They don't.

          Operators require something to act upon.

          > > > No. There is no "JavaScript undefined object". |undefined| is a
          > > > primitive value.
          > >
          > > We were both wrong. undefined is an object property. All other
          > > types are, however, objects.
          >
          > |undefined| is not an object property, it's a primitive value. If all
          > types were objects, typeof would return "object" for each of them,
          > and would be quite useless.
          >
          > typeof "" --> "string"
          > typeof new String("") --> "object"
          >
          > What you probably meant to say is that for most types, there exists
          > a built-in constructor with a similar name:
          >
          > "object" --> Object
          > "number" --> Number
          > "string" --> String
          > "boolean" --> Boolean
          > "function" --> Function
          >
          > "undefined" --> no constructor
          > "unknown" --> no constructor (used by IE)
          > "other-host-defined-type" --> depends on host environment

          Functions are objects. Types are derived from the few named constructor functions built into the language.

          > > > No, because as mentioned above there is no "undefined object",
          > > > and the *value* of |undefined| has nothing to do with strings.
          > >
          > > If the value of undefined is of type string then it has everything
          > > to do with the String object.
          >
          > The value of |undefined| can never be a string. Its value is
          > |undefined|, and its type is "undefined".

          No, undefined is a type not a string, and like all types they are output as string labels.

          > > The root of your confusion seems vested in collusion of value and
          > > type, which are not related except for type Number. String object
          > > is a perfect example of this because the object's name is String
          > > with a capital 'S', but the type represented by that object is
          > > 'string' with a lowercase 's'.
          >
          > Here's a String object: new String("hey").
          > It doesn't have a name. It has a constructor (String), and it has a
          > type ("object").

          It does have a name. Its name is an instance of the original String function, and so String is its name.

          > > If a variable is not defined you cannot test for any type other
          > > than undefined,
          >
          > Sure I can:
          > var foo;
          > if (typeof foo == "object") { ... }
          >
          > Doesn't make a lot of sense this way, but it could happen if the
          > variable foo were declared somewhere else (not your code), and you
          > don't know if it's currently defined or not.
          >
          > > which implies that types for values passed into
          > > that variable cannot be tested.
          >
          > I don't understand what you mean by that.

          You don't understand because you broke this out of its context. You referred to a single statement into two separate parts, and so the remaining fragment is an incomplete thought. Your example is flawed logic, because you cannot determine if a variable is storing an object if it is never provided any data or data type to represent.

          > > Here is how to test what I have claimed:
          > >
          > > xyzpdq === undefined //true
          > > typeof(xyzpdq) === 'undefined' //true
          > > typeof(undefined) === 'undefined' //true
          > > typeof(typeof(undefined)) === 'string' //true
          > > typeof(String) === 'function' //true
          > > typeof(typeof(String)) === 'string' //true
          > >
          > > I know that this is accurate, because this is how JavaScript
          > > evaluates in Firefox. If the ECMA standard is in disagreement with
          > > me then Firefox's interpretation of JavaScript is nonstandard or
          > > the standard is wrong.
          >
          > By definition, the specification can't be wrong (except for errata,
          > which are also available for download). Testing the type of
          > |typeof|'s return value doesn't make sense, because typeof will
          > always return a string. Your first example is dangerous and will blow
          > up with a ReferenceError if xyzpdq can not be resolved along the scope
          > chain.
          >
          >
          > - Conrad
          >

          Specifications are often wrong when they differ from the de facto implementation of the concepts addressed. This was the nature of the web during the years of the browser wars.

          My question is why would you ever perform any test on an undeclared variable? Why wouldn't you avoid such sloppiness by writing your code correctly and using JSLint to find your undeclared and unused variables?
        • Douglas Crockford
          ... What?
          Message 4 of 18 , Jul 9, 2009
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...>
            > They why are unary operators frowned upon by the jslint tool?

            What?
          • sandyhead25
            ... The most significantly common increment and decrement operators are frowned upon by the tool. The unary plus operator is not frowned upon, but is
            Message 5 of 18 , Jul 10, 2009
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
              >
              > --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@>
              > > They why are unary operators frowned upon by the jslint tool?
              >
              > What?
              >

              The most significantly common increment and decrement operators are frowned upon by the tool. The unary plus operator is not frowned upon, but is unpredictable if used against an object or array of various data types. The unary plus operator seems useless if not testing a value for type Number. Multiplication by 1 is significantly more reliable for testing if a value is of type Number as it takes the full value of a variable into consideration. The minus operator appears useful for converting values of type Number into polar opposites, but it is still subject to the same problems as the unary plus operator.

              I suppose the tool does not raise issue with plus or minus unary operators, but I never see these used and have learned to avoid them in my own code as bad style.
            • pauanyu
              ... This whole thread has spiraled out of control. Here s the simple answer: If you use (console === undefined), and console has not been declared, it will
              Message 6 of 18 , Jul 10, 2009
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                >
                > Why would you use
                > typeof(console) === "undefined"
                > instead of
                > console === undefined
                > which should be the same thing, but faster?
                >

                This whole thread has spiraled out of control. Here's the simple answer:

                If you use (console === undefined), and console has not been declared, it will throw a ReferenceError.

                If you use (typeof console === "undefined"), and console has not been declared, it will *not* throw a ReferenceError.

                There IS a difference between an undeclared variable and an undefined variable. A variable can be declared but undefined. An undeclared variable will throw a ReferenceError, but an undefined variable will not.

                That is why it is better to use typeof, because it will not throw a ReferenceError for undeclared variables.
              Your message has been successfully submitted and would be delivered to recipients shortly.