Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: JavaScript: The Definitive Guide Date: Sat, 20 Dec 2014 23:00:19 +0100 Organization: PointedEars Software (PES) Lines: 83 Message-ID: <2190158.3roXFedf12@PointedEars.de> References: <4ca7db7d-5a3b-457d-8601-aa9c72afab36@googlegroups.com> <4276616.1vbvTFgubW@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1419112823 27701 eJwNx8kBwCAIBMCWOJaNlKMg/Zdg5jfhVNYHBhETs3sgeUNxoKVWbOu2DNtCCq6n/1lp62AvfxS5ED4= (20 Dec 2014 22:00:23 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Sat, 20 Dec 2014 22:00:23 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNx0cBA0EMBDBK7uPAcVv+EC76yTU4BhYe5s9f//j+s9rF5PaTGNeTGcp1JB7lKFh4r4y0vapBOClGqH5j6RWI Cancel-Lock: sha1:+qZR5gAAPQ6+YvNlJHLgFcSE+1E= X-NNTP-Posting-Host: eJwNysERACEIA8CWzEFAynEw9F+Ct++lBaLTg+EczgbjGORo3rmS7E7WyGvW+XxXptyAf2uxHyWdEUI= Xref: csiph.com comp.lang.javascript:26365 Christoph M. Becker wrote: > Thomas 'PointedEars' Lahn wrote: >> He is writing „JavaScript“, but he is actually describing several >> ECMAScript implementations in Web browsers which may or may not have all >> of the described features in common, without being aware of it. > > Flanagan explains his use of the term "JavaScript" in a box in the > introduction chapter of the 6th edition[1]: > > | [...] In practice, just about everyone calls the language JavaScript. > | This book uses the name "ECMAScript" only to refer to the language > | standard. > > One may argue that this is awkward, but at least he informs the reader > about his chosen nomenclature. But it is not well-defined (“the language”), so whatever statement he makes using it is most certainly wrong. If so, it will be only subtly wrong, therefore misleading to the beginner who must acquire the misconception that they are dealing with only one programming language. >> He is _not_ describing several other ECMAScript implementations, and may >> be wrong with regard to the common features of those that he thinks he is >> describing, in Web browsers and elsewhere, being blissfully unaware of >> it. Somewhat of a result, so were you – until now. > > Indeed, it seems that the current (6th) edition does not even mention > the availability and usage of ECMAScript implementations other than in > Web browsers, what renders the title of the book deficient. Other than > that, it is to my knowledge the best available textbook on practical > browser side scripting. Taken with a grain of salt, I consider it a > decent *introduction* to this subject. A *grain*? > [1] This part of the book is (currently) available online via the book > preview ("Look inside") on amazon: > I do not have time for a full review, but if I had to pick three instances as to why it should be avoided, it would be these: The Introduction ----------------- His entire description of “Client-side JavaScript” is hopelessly outdated. Host objects have not been part of any implementation since more than a decade ago, and then only one, Netscape JavaScript (up to version 1.3). Operators ---------- The chapter on operators (chapter 4?) that has been random-access reviewed by Douglas Cornford before is *still* wrong. “Member access” should be “property access”, and is _not_ an operator. Calling a function (as a function) is _not_ an operation. The term “operator precedence” simply does not apply to several syntactical constructs listed there. The only improvement that I can see is that the “Array operator” is no longer there; it has been replaced by “member access”. But that chapter is incomplete in the preview. Inheritance ------------ There are neither classes nor modules in implementations of ECMAScript Edition 5, yet there is an entire chapter “Classes and Modules” and a section “Classes in ECMAScript 5”. One can read subsection titles like “Defining a Subclass”. In that line of thought, there is an important difference between Date.now() and Date.prototype.setDate() [the latter is implicitly inherited, the former is not], but he writes the latter “Date.setDate()” (like many other people who are ignorant of prototype-based inheritance). I can not only not recommend this bug^H^Hook, but I have to *strongly* recommended against it. (Like all previous editions of it.) -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.