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

729Re: console read only

Expand Messages
  • sandyhead25
    Jul 9 2:56 PM
    • 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?
    • Show all 18 messages in this topic