Prev: Limit of 4K
Next: Detecting Internet Explorer 6
From: VK on 31 Oct 2009 14:35 > > That's a wrong statement, you must be thinking of VBScript where > > indeed all variables independently on the current value are of the > > same Variant type. JavaScript is a *loosely typed* language, that > > means that each variable is of some certain type but this type can be > > changed to another one at runtime. > > I doubt anyone is thinking of VBScript at this juncture. And you > aren't thinking at all (as usual). With your own programming skills I would remain silent, really. [nonsense skept]
From: VK on 31 Oct 2009 15:04 Lasse Reichstein Nielsen wrote: > Variables can have types in JavaScript 2.0, but not in ECMAScript so > far. Values have types. Variables have a value, but not an inherent > type. That is another (but a very round around) way to say that JavaScript is a loosely typed language. There are untyped languages like VBScript, where no matter what value is currently assigned to a variable, its type is the same universal Variant. There are loosely typed languages like JavaScript where at each moment each variable has a strictly defined type depending on the value it points to. There are strictly typed languages like Java where on initialization stage we have to indicate what type of values this variable can point to, and we cannot change it at runtime. JavaScript from the beginning and till now is loosely typed language. It might add optional strictly typed features in the future to please some C-grounded hearts :) but so far this disaster is not actual. > >> Null is a primitive value in javascript. > > > Another wrong statement: null in JavaScript is an object with the only > > property null: > > window.alert(typeof null) // 'object' > > No, null is a primitive (i.e., non-object) value. > Notice the specification of the typeof operator needs a special case > for null, because it is not an object (ECMA 262 section 11.4.3). It needs a separate row because it goes by types, and Null type returns "object". But OK, "null is a primitive value with typeof "object" by a bizarre demand of specs" > > This way by assigning null to an object reference, we are > > dereferencing the said object. > > You can't assign a value to a value (object references are values), > and I don't think "dereferencing" means what you think it means. Yes, "unlink" might be better. > > If it is the last existing reference > > then the relevant scavenger will be marked as garbage collection > > available on the next GC check. Not sure what is so alien here in > > comparison with other languages. > > True, if you overwrite a variable holding an object reference with > null, that might make the object eligable for garbage collection, but > the same happens if you assign a number to the variable. Nothing > non-primitive about null in that case. Yes, in JavaScript one may "unlink" an object by setting all variables pointing to it to 0, 1, "foobar" or anything else. It is possible in a loosely typed language yet extremely awkward. In strictly typed languages though it will lead to an error because you cannot assign non-reference value to a reference value variable. So to uniform JavaScript with the common programming practice and do not make your code looking silly it is still suggested to "unlink" using null assignments, not any other fantasy values. > >> | Another misleading assertion was "Though ECMA-262 doesnt indicate a > >> | way to access the Global object directly [ ]". > > >> Plainly false. In global context: > > >> var global = this; > > > Plainly false: in global context [this] refers to the window host > > object, not to Global. > > What makes you think they are different? :) For Gecko and IE: respective explanations from MDC and MSDN and team blogs, I posted the relevant materials since 2006 here. > In a browser setting, the global object and the "this" value is > actually not necessarily the same object, but ECMA-262 says nothing > about browsers. > It does say that the "this" value for code executed in a Global > Context is the global object. If browsers differ, it's because they > are not completely ECMA-262 compliant (with good reason, usually > security related). I thought the topic of discussion is about practical programming and a book giving advises on it. If we want to discuss programming issue for an abstract ECMA 262 3rd.ed. machine then it will be totally another topic IMHO ;)
From: David Mark on 31 Oct 2009 15:19 On Oct 31, 2:27 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: [...] > > What makes you think they are different? :) Are you really asking VK to answer this? :) > > In a browser setting, the global object and the "this" value is > actually not necessarily the same object, but ECMA-262 says nothing > about browsers. > It does say that the "this" value for code executed in a Global > Context is the global object. If browsers differ, it's because they > are not completely ECMA-262 compliant (with good reason, usually > security related). I don't know of any ECMAScript implementation that varies in that regard (browser or not). It certainly wouldn't be a good implementation. But VK is hung up on the window object, which isn't specified anywhere other than in browser documentation (an aside in ECMA-262 about browsers notwithstanding). "Additional host defined properties. This may include a property whose value is the global object itself; for example, in the HTML document object model the window property of the global object is the global object itself." This is not a standard, but is sometimes cited as if it were. In reality, resemblances between that *implementation dependent* host object and the Global Object may or may not indicate they are the same object. Doesn't matter at all for most developers. Then there's VK...
From: Garrett Smith on 31 Oct 2009 23:18 VK wrote: > Garrett Smith wrote: >> Javascript variables are untyped. > It is hard to imagine anyone taking that the statements you have made seriously. How could you believe what you have written? I hope that it is not some form of sabotage. > That's a wrong statement, you must be thinking of VBScript where > indeed all variables independently on the current value are of the > same Variant type. JavaScript is a *loosely typed* language, that > means that each variable is of some certain type but this type can be > changed to another one at runtime. > No, my statement is correct. Variables are untyped. Nowhere are variables defined to have a type. Unless you can back that statement up with some thing from the specification. Alas, you have not; nor can you, so the reader is left with the options of taking your word over the specification. Variables are initialised to undefined when created. var x; The value of a variable can change in an assignment expression: x = 10; x = "foo"; x = {}; All of that is allowed by the specification. Nowhere does the specification mention variable types. If x were typed, it would not have a very clear type, now, we see the value change from |undefined| to a number, a string value, finally an object. A /value/ could be said to be typed, as there are many places in the specification that mention if [value] is a [type], or:- | A string value is a member of the type String A variable is not a member of any Type. That is not how javascript works. Contrast that to Java, where variables are typed. <URL: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html > | every variable and every expression has a type that is known at | compile time. Types limit the values that a variable (�4.12) can hold | or that an expression can produce, limit the operations supported on | those values, and determine the meaning of the operations. Strong | typing helps detect errors at compile time. And in Java:- String x = "foo"; x = 10; // won't compile. However: String = 10 + ""; should compile fine. >> Null is a primitive value in javascript. > > Another wrong statement: null in JavaScript is an object with the only > property null: No, null is a primitive value. Being a primitive value, null has no properties, and so cannot have a property named "null". A primitive value is not an object or reference. The Null type is not an object Type. | 4.3.12 Null Type | The type Null has exactly one value, called null. | 4.3.2 Primitive Value | A primitive value is a member of one of the types Undefined, Null, | Boolean, Number, or String The ECMA specification is clear that null is a primitive value, not an object. Need more evidence? 9.1 ToPrimitive | Input Type Result | Undefined The result equals the input argument (no conversion). | Null The result equals the input argument (no conversion). | ... If Null type were an object type, it would not make much sense for ToPrimitive to convert null to null. OTOH, in reality, null is a primitive: | 7.8.1 | The value of the null literal null is the sole value of the Null type, | namely null. 10.2.3 | note that null is not an object > window.alert(typeof null) // 'object' Works as designed (though that design is questionable). The result of the typeof operator does make null an object. The value null a primitive value. > This way by assigning null to an object reference, we are > dereferencing the said object. If it is the last existing reference > then the relevant scavenger will be marked as garbage collection > available on the next GC check. Not sure what is so alien here in > comparison with other languages. > I'm having a hard time following that explanation. In contrast, the specification clearly explains null. >> | Another misleading assertion was � "Though ECMA-262 doesn�t indicate a >> | way to access the Global object directly [�]". >> >> Plainly false. In global context: >> >> var global = this; > > Plainly false: in global context [this] refers to the window host > object, not to Global. Let's do not mix "syntax sugar" added atop in > some engine implementations with the actual mechanics, it might be > dangerous. The |this| value in global context is the global object. This is clearly explained in ECMA-262 specification, s10.2.1. | The |this| value is the global object. It is your word against the ECMA-262 r3 specification. Do you really think the specification is wrong and you are correct? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: VK on 1 Nov 2009 05:34
VK wrote: > > That's a wrong statement, you must be thinking of VBScript where > > indeed all variables independently on the current value are of the > > same Variant type. JavaScript is a *loosely typed* language, that > > means that each variable is of some certain type but this type can be > > changed to another one at runtime. Garrett Smith wrote: > No, my statement is correct. Variables are untyped. > > Nowhere are variables defined to have a type. (further similar nonsense removed) You know guys, at the run of one week you just killed me, really. For some time I did believe that some posters here are professional programmers with CS diplomas trying to learn yet another language different from C++. So I attributed their obvious beserknesses to the classical CS education - so being forgiven to some rather wide extend. But the discussion at "Implicit object constructor misinterpretation" and comments like here did force me to change my mind. Now if I ever believe that you had any CS education, then only in some conspiratorial school "Witnesses of Integer" or similar of the kind :) Because no normal place you could came from with such a luggage of pseudo-philosophic twisted definitions of nearly anything from the the most core programming entities. I am not arguing with you anymore. You are definitely right, the Earth is flat and stays on three elephants. For other possible readers a few random links on the subject below. Also of course do not take some anonymous VK poster as being right by definition. Go and ask at MIT, Berkley, Carnegie Mellon or other reputable CS department for explanations. Typeless language http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_eves.mspx Loosely (dynamically) typed language http://www.computerhope.com/jargon/l/looslang.htm http://msdn.microsoft.com/en-us/library/14cd3459%28VS.85%29.aspx http://www.java2s.com/Tutorial/JavaScript/0100__Number-Data-Type/Variablesarelooselytyped.htm see also: type coercion Strongly (statically) typed language http://www.computerhope.com/jargon/s/strolang.htm |