Errata for JavaScript: The Definitive Guide

The function "union"'s comment section notes that "If o and p have properties by the same name, the values from o are used". It should read "the values from p are used".

Note from the Author or Editor:
change the comment as the reader suggests

Object.prototype.isPrototypeOf(o) // => true: p inherits from Object.prototype Should read, Object.prototype.isPrototypeOf(o) // => true: o inherits from Object.prototype

Note from the Author or Editor:
The reader is correct that there is a problem, but the proposed solution is wrong. Change the line: Object.prototype.isPrototypeOf(o) // =>; true: p inherits from Object.prototype To: Object.prototype.isPrototypeOf(p) // =>; true: p inherits from Object.prototype

The second sentence of this paragraph reads: "All indexes are property names, but only property names that are integers between 0 and 2^32 - 1 are indexes." This is misleading. According to the ECMAScript spec (section 15.4, both the 3rd and 5th edition): "A property name P (in the form of a String value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 2^32 - 1." So the second sentence of your paragraph should read: "All indexes are property names, but only property names that are integers between 0 and 2^32 - 2 are indexes." Thanks so much for writing this book!

Note from the Author or Editor:
Good catch! Change 2<superscript>32</superscript>-1 to 2<superscript>32</superscript>-2

In Example 8-3, the nested patched_extend(o) function references the protoprops variable defined in its surrounding function, but the assignment of an array of strings to the protoprops variable is unreachable code. The declaration of the protoprops variable will be hoisted, but since the unnamed outer function will always return either the extend(o) or the patched_extend(o) function before the assignment statement itself is executed, the value of protoprops should always be undefined.

Note from the Author or Editor:
This is another good catch. Move the 4 lines beginning with the blank line before this one: // This is the list of... Up so that they appear right after this line: // properties of Object.prototype. You should end up with a 4-line comment block, followed by a blank line, followed by a one line comment, followed by 2 lines beginning "var protoprops = " followed by the line "return function patched_extend(0) {" and all the code that follows that. The example should still end with the line "}());"

<pre> Page 208: Section 9.4: First paragraph: ... an object inherits properties from its prototype, even if the prototype changes after the object is created. is at least misleading. 'prototype' is the name of a pointer/reference to a object which contains the prototypical properties since arrays/objects are referenced by pointer/reference (section 3.7). This is a perfect example of pointer/reference access to one object using different copies of the same pointer/reference. I think saying 'even if the prototype's properties, but not the actual prototype, changes, since the prototype is referenced by pointer/reference ...' would be clearer and let one see just why changes in the prototype do affect old objects. SAMPLE: ======= I will look at an object which is an instance of a class for which the prototype is created as a property of the constructor. I will use 'print' for output (the spider monkey stand alone interpreter's output function). If you change the prototype itself, the POINTER to the object of prototypical values, then new objects use the new prototype but *OLD OBJECTS USE THE OLD PROTOTYPE*. The new objects (objects created after the prototype changes) contain pointers to the new object containing the new prototype values while the old objects use the old prototype (pointer/reference to the old prototype's object). function Test1() {};Test1.prototype={a:1,b:2} T=new Test1 print(T.a);print(T.b);print(T.c) Test1.prototype={a:10,b:20,c:30} U=new Test1 print(T.a);print(T.b);print(T.c) print(U.a);print(U.b);print(U.c) gives 1, 2, undefined [original T before the prototype has changed] 1,2, undefined [original T AFTER the prototype has changed] <-- 10,20,30 [U - created AFTER the prototype has changed] T retains the old prototype, i.e. the pointer to the old prototype's object. On the other hand, if you change the CONTENTS of the prototype object but not the prototype (i.e. the pointer/object containing the values): function Test2() {};Test2.prototype={a:1,b:2} V=new Test2 print(V.a);print(V.b);print(V.c) Test2.prototype.a=10;Test2.prototype.b=20;Test2.prototype.c=30 W=new Test2 print(V.a);print(V.b);print(V.c) print(W.a);print(W.b);print(W.c) Then one gets: 1, 2, undefined [original V before the prototype has changed] 10,20,30 [original V AFTER the prototype has changed] <-- 10,20,30 [W - created AFTER the prototype has changed] If an instance of an class contained a reference to its constructor (instead of the constructor's prototype) and actually used that to access the prototype object of its class/constructor (rather than having a pointer to the prototype object used when it was constructed itself) then one could change the prototype object (not just its contents) (as a property of the constructor) and the changed prototype would affect both new *and old* instances: function Test3() {this.constructor=Test3}; Test3.prototype={a:1,b:2} X=new Test3 print(X.constructor.prototype.a);print(X.constructor.prototype.b);print(X.constructor.prototype.c) Test3.prototype={a:10,b:20,c:30} Y=new Test3 print(X.constructor.prototype.a);print(X.constructor.prototype.b);print(X.constructor.prototype.c) print(Y.constructor.prototype.a);print(Y.constructor.prototype.b);print(Y.constructor.prototype.c) produces: 1, 2, undefined [original X before the prototype has changed] 10,20,30 [original X AFTER the prototype has changed] 10,20,30 [Y - created AFTER the prototype has changed] Now I wonder what intricacies are created when a constructor which is an internal function to another is called - if the constructor's 'prototype' is set equal (f.prototype=p) to an internal variable of the containing function ... or various properties of the prototypical object are set equal to internal variables .... </pre>

Note from the Author or Editor:
Okay, change "even if the prototype changes" to "even if the properties of the prototype change"

"... and whose name is the HTMLElement ..." should read: and whose value is the HTMLElement

Note from the Author or Editor:
yes, make that change.

'Any <span> with "warning" and "fatal" in its class' shoud read 'Any <span> with "fatal" and "error" in its class'

Page 503; Example 18-5, first paragraph following: "HTML forms generate POST requests by default." Is that true? Perhaps XMLHTTPRequest does, but do HTML forms default to POST? Page 502 and 503: Example 18-4: encodeFormData() function. I believe there are other locations where this procedure is used (decoding data, etc.). The code indicates that to *encode* data, first replace spaces with "+" then encodeURIComponent. To *decode* submitted data, first decodeURIComponent and then replace "+" with space (I am *sure* I saw that decoding somewhere, using 'unescape' - but it seems to be wrong). Done that way, spaces and "+"s in the original text are mixed and cannot be unmixed. encodeURIComponent appears *not* to act precisely the way a form submission acts in encoding items. In submission of a real form on an HTML page, submitted data first has "+"s encoded (HEXed/escaped) but SPACES ARE LEFT ALONE (not escaped). After that step (escaping) spaces are converted to "+" as the final encoding step. Apparently this is a hold over from old formats when only plain text (no "+"s!) with spaces was expected (if that is the case, then just convert spaces to + to send it without problems and there is no mixing of "+" and space as the original text had no "+"s). That is the data (first escape some characters, including "+" but EXCLUDING spaces, and then change spaces to "+"). I guess, if done now, both "+" and spaces would simply be escaped. On the other hand, encodeURIComponent seems to escape both spaces AND "+" - a bit different from www-form encoding (in which case don't do any of the space/+ conversions in creating data, there won't be any problem or spaces or "+" after endodeURIComponent). Hopefully servers will handle decoding of submitted data (they will try first to convert "+" to space, but find none, and then unescape the result ... and it comes out right). On the other hand, I am sure there is code in 'Javascript, The Definitive Guide" for DECODING responses and if the response is sent back 'www-form-encoded' one has to decode it properly (first change "+" to space and *then* unescape which will recover any "+"s in the original data).

Note from the Author or Editor:
In the first block of code on page 503, change these lines: name = encodeURIComponent(name.replace(" ", "+")); // Encode name value = encodeURIComponent(value.replace(" ", "+")); // Encode value To: name = encodeURIComponent(name).replace("%20", "+"); // Encode name value = encodeURIComponent(value).replace("%20", "+"); // Encode value In the last paragraph of page 503, cut the lines: HTML forms generate POST requests by default, but they can also make GET requests. (When the purpose...than POST.) And replace them with these: Form data can also be submitted using a GET request, and when the purpose of a form submission is to make a read-only query, GET is more appropriate than POST.

In the 10th line of example there is comma missing after } (after third parameter of requestFileSystem).

Note from the Author or Editor:
Change these two lines: // Use fs here } To add a comma after the brace: // Use fs here },

The last sentence says that the default attribute values of absent members are false or null, but ECMAScript language defines them false or "undefined", not null. This definition is shown as Table-7 on ECMA-262 edition 5.1, within the Object Type section (8.6.1 actually).

Note from the Author or Editor:
Change "false or null" to "false or undefined"

At least in 'WebKit' you need to call document.createEvent('Events') to create a simple event object (the book states that document.createEvent('event') will do).

Note from the Author or Editor:
Please fix.