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

Re: console read only

Expand Messages
  • sandyhead25
    ... I did not say the test was incorrect. I only said it was inefficient and likely did not accomplish what he expected. ... Unary operators are typically
    Message 1 of 18 , Jul 8, 2009
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
      >
      > "sandyhead25" <austin.cheney@> wrote:
      > > You seem to have confused the result of the test for the operations
      > > imposed within the test decision.
      >
      > No, the confusion is yours. Marcel's test and explanation were correct:

      I did not say the test was incorrect. I only said it was inefficient and likely did not accomplish what he expected.

      > > The typeof operator only tests for the type of the value
      > > represented by a variable.
      >
      > No, typeof works on expressions (more precisely UnaryExpressions),
      > including variables and object properties. That means it will also work on implicit properties of the global object, like |console|.

      Unary operators are typically regarded as poor practice in JavaScript and still require use of a name variable. This is not really relevant to the subject at hand and does not challenge what I said. typeof returns the object or property type of a variable name as a string value.

      > > If a variable is undefined then it is assigned to the JavaScript
      > > undefined object.
      >
      > 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.

      > > The value of that object is 'undefined' and its type is also
      > > 'undefined' instead of string.
      >
      > The value of undefined is undefined, obviously, and its type (as
      > returned
      > by typeof) is "undefined" (yes, a string).

      No, that is not obvious. Undefined is an object property that has a value of 'undefined' as type String. If this were obvious we would not be having this conversation.

      > > The value of the undefined object, however, is always string output
      > > of 'undefined'.
      >
      > 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.

      > > As a result you have accomplished nothing by attempting to filter
      > > the value of the undefined object apart from its type.
      >
      > I can't make any sense of that statement. Marcel's example is the
      > correct way of testing if a variable or property is defined.

      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'.

      > > The only way to accurately test for a variable's data type is to
      > > ensure it is actually assigned a value.
      >
      > That's nonsense. "undefined" is one of the basic types in JavaScript,
      > and you can (and should) test for it with the typeof operator.

      If a variable is not defined you cannot test for any type other than undefined, which implies that types for values passed into that variable cannot be tested.

      > I addition to what Marcel wrote, another potential drawback of the
      > suggested |if (console === undefined)| is that the special |undefined|
      > value was not supported by some (very old) browsers, leading to
      > the amusing error message "undefined is not defined." So, if you want
      > to be ultra-compatible, typeof is the safer choice. In less ancient
      > browsers, you could also test for the console object with
      > |if ("console" in window)|, but then you'll have to declare |window|
      > as /*global*/ to make it work with JSLint. If this check is in the
      > global
      > context, |if ("console" in this)| should also work.
      >
      > I know you're new at this, but please check your facts before you
      > start lecturing. Here, read this:
      >
      > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pd\
      > f
      >
      > It should clear a few things up for you.
      >
      >
      > - Conrad
      >

      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.
    • sandyhead25
      ... I have discovered the root of this complication. If a variable is declared but not assigned or not used this text works perfectly fine. If the variable
      Message 2 of 18 , Jul 8, 2009
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Marcel Duran <contact@...> wrote:
        >
        > by "work" I meant "will evaluate the expression" not the result itself.again:
        > if console is not defined, your test, if (console === undefined) will raise
        > a ReferenceError exception.
        > If you still don't believe, try it yourself, go into your firebug console
        > and type:
        >
        > if (foobar === undefined) {}
        >
        > and run...
        >
        > assuming foobar wasn't prior defined elsewhere you'll get a "ReferenceError:
        > foobar is not defined" message.
        >
        > Marcel
        >

        I have discovered the root of this complication. If a variable is declared but not assigned or not used this text works perfectly fine. If the variable is never declared the test fails. If you were attempting to evaluate declarations for potentially unknown namespace conflicts this is the way to go. Otherwise, why not always declare your variables at the top of your function to avoid such problems?
      • 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 3 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 4 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 5 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 6 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 7 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 8 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.