FAQ Update 9.85 Dated 2007-08-31
FAQEditor
Section 3.1 changed to read:
The only book currently endorsed by c.l.j. regulars is:
JavaScript: The Definitive Guide, 5th Edition By David Flanagan
ISBN:0-596-10199-6
Also by David Flanagan: JavaScript Pocket Reference, 2nd Edition. ISBN
0-596-00411-7 for language and API reference alone.
The errata should be considered a must read along with the book.
http://www.oreilly.com/catalog/jscript5/
Errata:
http://www.oreilly.com/catalog/jscript5/errata/
David Flanagan's Blog Site:
http://www.davidflanagan.com/
Section 4.22 reworded and the MSDN URL changed.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
FAQ Notes: http://www.jibbering.com/faq/faq_notes/faq_notes.html
ECMAScript Language Specification via FAQ2.6
Richard Cornford
> FAQ Update 9.85 Dated 2007-08-31:
>
> Section 3.1 changed to read:
>
> The only book currently endorsed by c.l.j. regulars is:
>
> JavaScript: The Definitive Guide, 5th Edition By David
> Flanagan ISBN:0-596-10199-6
That still isn't technically true, as there have been no such
endorsements (in the sense in which the 4th edition was explicitly
endorsed by at leas a handful of regulars). Still, I would be willing to
go with that wording at present, if only to put a stop to the pointless
quibbling. The 5th edition does not seem to be worse than the 4th so I
think that those who did endorse the 4th would be as willing to endorse
the 5th.
I think we are, once again, suffering from the obvious fact that those
who are already familiar with javascript, web browsers and the DOM are
not motivated to by and read reference works on the subject (and the
book's authors are not motivated to pay such individuals to do reviews
of their books, as the results will likely be heavily critical).
> Also by David Flanagan: JavaScript Pocket Reference, 2nd Edition.
> ISBN 0-596-00411-7 for language and API reference alone.
>
> The errata should be considered a must read along with the book.
While pointing out that there is an errata is a good idea I think it
would be good if the fact could better express that the errata will only
contain corrections that the author is willing to recognise. For
example, the subdivision of the book into 'core' and 'client side'
javascript, justified in the first couple of editions, an anachronism by
the 4th and a positive mistake in the 5th, is unlikely to ever be
'corrected' in an errata. And neither is much of the misleading and
ambiguous terminology employed in the book, or the inadequate discussion
of the use of - navigator.userAgent.
> http://www.oreilly.com/catalog/jscript5/
> Errata:
> http://www.oreilly.com/catalog/jscript5/errata/
> David Flanagan's Blog Site:
> http://www.davidflanagan.com/
I don't think that David Flanagan's blog deserves a mention at all.
Richard.
David Golightly
wrote:
> FAQEditor wrote:
> > FAQ Update 9.85 Dated 2007-08-31:
>
> > Section 3.1 changed to read:
>
> > The only book currently endorsed by c.l.j. regulars is:
>
> > JavaScript: The Definitive Guide, 5th Edition By David
> > Flanagan ISBN:0-596-10199-6
<snip>
> I think we are, once again, suffering from the obvious fact that those
> who are already familiar with javascript, web browsers and the DOM are
> not motivated to by and read reference works on the subject (and the
> book's authors are not motivated to pay such individuals to do reviews
> of their books, as the results will likely be heavily critical).
As noted in this thread: http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/6887efe0fe05543c
JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, Norris
Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, Todd
Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. Reviewers of
previous editions include Brendan Eich and Waldemar Horwat.
-David
FAQEditor
> FAQEditor wrote:
<snip>
>> http://www.oreilly.com/catalog/jscript5/
>> Errata:
>> http://www.oreilly.com/catalog/jscript5/errata/
>> David Flanagan's Blog Site:
>> http://www.davidflanagan.com/
>
> I don't think that David Flanagan's blog deserves a mention at all.
The blog site has been removed from my local copy.
Richard Cornford
Your point being?
Richard.
Dr J R Stockton
Fri, 31 Aug 2007 17:11:33, FAQEditor <clj...@comcast.net> posted:
For the next update, but needing no announcement,
>JavaScript: The Definitive Guide, 5th Edition By David Flanagan
by
or
David Flanagan's "JavaScript: The Definitive Guide", 5th Edition.
>The errata should be considered a must read along with the book.
----------- ... ugh!
>The errata should be read with the book.
Actually, the errata should be used to correct the book.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html>
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
David Golightly
wrote:
> David Golightly wrote:
> > On Sep 1, 11:49 am, Richard Cornford wrote:
> >> not motivated to pay such individuals [who are already familiar with javascript, web browsers and the DOM] to do reviews of
> >> their books, as the results will likely be heavily critical....
>
> > As noted in this thread:
>
> > JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford,
> > Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper,
> > Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld.
> > Reviewers of previous editions include Brendan Eich and
> > Waldemar Horwat.
>
> Your point being?
>
> Richard.
The point being evident, that you claimed that the book's authors are
not motivated to hire reviewers who are familiar with the subject
matter. The above list of names would indicate to the contrary.
-David
Richard Cornford
news:1188688954.2...@50g2000hsm.googlegroups.com...
> On Sep 1, 1:59 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>> David Golightly wrote:
>>> On Sep 1, 11:49 am, Richard Cornford wrote:
>>>> ... the book's authors are
>>>> not motivated to pay such individuals
>>>> [who are already familiar with javascript, web browsers
>>>> and the DOM] to do reviews of
>>>> their books, as the results will likely be heavily critical....
>>
>>> As noted in this thread:
>>>http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...
>>
>>> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford,
>>> Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper,
>>> Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld.
>>> Reviewers of previous editions include Brendan Eich and
>>> Waldemar Horwat.
>>
>> Your point being?
> The point being evident,
No it was not evident. Now you appear to be asserting that the above
list represents individuals who are "familiar with javascript, web
browsers and the DOM", though you have in no way demonstrated that.
> that you claimed that the book's authors
When did David Flanagan become the authors of javascript reference
books?
> are not motivated to hire reviewers who are familiar
> with the subject matter. The above list of names would
> indicate to the contrary.
The above list says nothing about the motivations of the authors of
javascript reference books (it just may say something about the actions
of an author of a single javascript reference book).
Richard.
David Golightly
wrote:
> "David Golightly" <davig...@gmail.com> wrote in message
>
> news:1188688954.2...@50g2000hsm.googlegroups.com...
>
>
>
> > On Sep 1, 1:59 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> > wrote:
> >> David Golightly wrote:
> >>> On Sep 1, 11:49 am, Richard Cornford wrote:
> >>>> ... the book's authors are
> >>>> not motivated to pay such individuals
> >>>> [who are already familiar with javascript, web browsers
> >>>> and the DOM] to do reviews of
> >>>> their books, as the results will likely be heavily critical....
>
> >>> As noted in this thread:
> >>>http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...
>
> >>> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford,
> >>> Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper,
> >>> Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld.
> >>> Reviewers of previous editions include Brendan Eich and
> >>> Waldemar Horwat.
>
> >> Your point being?
> <snip>
> > The point being evident,
>
> No it was not evident. Now you appear to be asserting that the above
> list represents individuals who are "familiar with javascript, web
> browsers and the DOM", though you have in no way demonstrated that.
Likewise, you have in no way demonstrated your claim that the book's
author is NOT motivated to pay appropriate subject-matter experts to
review the book. In fact, by disputing that, you manage to undermine
your own credibility by questioning the credibility of these well-
known experts.
To name a few:
Douglas Crockford - Senior JavaScript architect, Yahoo!
Norris Boyd - creator of the Rhino JavaScript interpreter
Peter-Paul Koch - freelance developer and established author of
quirksmode.org
Christian Heilmann - established web developer, standards advocate,
and technical author
Todd Ditchendorf - software engineer at Apple Computer, freelance
developer, standards advocate
The supposed controversy lies in the lack of an objective standard for
"quality" in this domain, though the best approximation we can achieve
is by taking the words of established, creative, inventive, successful
developers who have produced work and created software outside of
esoteric examples and self-righteous language lawyering on Usenet.
Perhaps I personally fall in that last category, or somewhere else, I
don't know. But if you can't acknowledge the expertise of the proven
experts, well, then, why should anyone listen to you?
> > are not motivated to hire reviewers who are familiar
> > with the subject matter. The above list of names would
> > indicate to the contrary.
>
> The above list says nothing about the motivations of the authors of
> javascript reference books (it just may say something about the actions
> of an author of a single javascript reference book).
The thread started in the particular, you brought it into the general,
now I (though admitting a typo) have attempted to bring it back to the
particular.
-David
Richard Cornford
> On Sep 1, 4:49 pm, Richard Cornford wrote:
>> David Golightly wrote in message
I did not make such a claim. I claimed that the authors of javascript
reference books where not motivated to ... . The existence of reviews of
a single javascript reference book (regardless of the supposed technical
qualifications of the people responsible) does not speak for the
motivations of the authors of javascript reference books in general, or
actually say anything the motivations of David Flanagan (as his
suggested involvement has only be implied).
> In fact, by disputing that,
Disputing what? That the list of individuals you posted does not
necessarily represent a list of individuals "familiar with javascript,
web browsers and the DOM"?
> you manage to undermine your own credibility by questioning
> the credibility of these well- known experts.
>
> To name a few:
> Douglas Crockford - Senior JavaScript architect, Yahoo!
Douglas has been contributing to this group for longer than I have. I
have absolutely no doubt that his understanding of javascript, as a
language, is second to none, but that is just one of the three criteria
I stated.
> Norris Boyd - creator of the Rhino JavaScript interpreter
Again someone who can be expected to understand javascript as a
language, but what does this qualification say about someone's
familiarity with web browsers? How many browser use Rhino as a
javascript engine? I can only name one.
> Peter-Paul Koch - freelance developer and established author of
> quirksmode.org
I don't have time to go into the shortcomings of quirksmode.org here
again.
> Christian Heilmann - established web developer, standards advocate,
> and technical author
So that implies familiarity with the DOM, but necessarily javascript as
a language or web browsers in general.
> Todd Ditchendorf - software engineer at Apple Computer,
> freelance developer, standards advocate
Ditto.
I notice that you have not included Brendan Eich in this list. An
undoubted expert in his own right, the last word on the implications of
the implementation details of the javascript engine in
Netscape/Mozilla/Gecko browsers on the execution of actual
JavaScript(tm) code. But not necessarily someone who has anything useful
to say on the on the subject of the issues of scripting for IE, Opera or
the host of other non-Gecko browsers that exist.
> The supposed controversy lies in the lack of an objective
> standard for "quality" in this domain, though the best
> approximation we can achieve is by taking the words of
> established, creative, inventive, successful developers
> who have produced work and created software outside of
> esoteric examples and self-righteous language lawyering
> on Usenet.
An appeal to authority is always a poor criteria. But what a set of
qualifications to choose? When, and in what sense does someone become
"established"? Of what value is "creative" if the creations are in an
unrelated area, and it is a pretty subjective criterion anyway. The same
goes for "inventive". And if "successful developer" means 'well paid'
then that certainly says nothing significant about pertinent expertise.
A much better starting point for considering someone's expertise in the
pertinent areas is to look at their browser scripts and see how
well/comprehensively it identifiers and handles/avoids the issues of
cross browser scripting and how well it employs the language. There may
be a great deal of subjective judgment in that, and much that can be
expected to be the consequence of personal style, but there is also much
to be learnt about the author's 'expertise' in the process.
> Perhaps I personally fall in that last category, or
> somewhere else, I don't know.
And nobody else will know either until you start posting code instead of
just talking about it.
> But if you can't acknowledge the expertise of the proven
> experts,
In what sense am I not acknowledging the expertise of the "proven
experts"? Where I am not already familiar I am asking to see some proof,
and where I am familiar I am just questioning the applicability of the
specific expertise to three criteria I proposed.
> well, then, why should anyone listen to you?
People have to make their own minds up as to who they are going to
listen to.
>>> are not motivated to hire reviewers who are familiar
>>> with the subject matter. The above list of names would
>>> indicate to the contrary.
>>
>> The above list says nothing about the motivations of the
>> authors of javascript reference books (it just may say
>> something about the actions of an author of a single
>> javascript reference book).
>
> The thread started in the particular, you brought it into
> the general,
I made a general statement about the authors of javascript reference
books. General statements tend not to be true for all individuals who
may seem be covered by the generality. Yet still we have a situation
where the only contender for inclusion in the FAQ is Flanagan's book,
and that is with all of its manifest shortcomings.
> now I (though admitting a typo) have attempted to bring it
> back to the particular.
The particular that we might bring it 'back' to may be shortcomings of
Flanagan's book. So, for example, last October when, in response to a
question posted here on the XML HTTP request code published in the 5th
edition, I pointed out that as implemented the code would fall foul of
the IE (<=6) memory leak problem (along with some other issues) I was
either correct in my comment or I was mistaken. The fact that the errata
for the book now include all of the corrections I proposed suggests that
my criticisms were valid and just. That memory leak issue, and the cause
and effect relationships behind it, are hardly a recent discovery (I was
posting demonstrations of the issue here back in mid 2003 and it was
certainly a known (if a little misunderstood) issue at that time).
That was a real and demonstrable issue with Flanagan's book, and I can
find plenty more of them, and back them up with reasoned argument and
practical demonstration. It may be the case that Flanagan's book is the
lest bad javascript book available by a very large margin (I have read
sections of other javascript books where every statement made in entire
chapters were factually false, so the quality of the competition is very
poor) but if you propose a list of "expert" reviewers who read that book
and (by your implication) fail to find fault with it I have reasonable
grounds for questioning the applicability of the proposed "expertise" of
those reviewers to the real world practice of browser scripting.
Richard.
Dr J R Stockton
, Sun, 2 Sep 2007 04:02:44, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>
>That was a real and demonstrable issue with Flanagan's book, and I can
>find plenty more of them, and back them up with reasoned argument and
>practical demonstration.
To be constructive, you could do that, and send it to David Flanagan so
that the Sixth Edition could be improved. His E-mail address is easy to
find.
But, as regards the FAQ, that's a detail.
The FAQ maintainer seems to have wanted to say something equivalent to
"The book ... is strongly endorsed by all experts in this newsgroup,
being (when read in conjunction with its Errata) near enough perfectly
accurate" - and cannot find anything to replace the ellipsis.
But that's not what the intended reader needs; all he needs is something
like "One of the best books is ..." - and that ellipsis *is*
replaceable.
In FAQ Section 3, before 3.1, there could be something like : "Be aware
that no source will be absolutely reliable, and any source may become
outdated."
The FAQ links to ECMA-262 3rd Edn, but lacks a reference to its Errata.
Googling for "ecmascript errata" finds 80400 links, but happily the
first is good.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Richard Cornford
> Richard Cornford posted:
>>
>> That was a real and demonstrable issue with Flanagan's book,
>> and I can find plenty more of them, and back them up with
>> reasoned argument and practical demonstration.
>
>
> To be constructive, you could do that, and send it to David
> Flanagan so that the Sixth Edition could be improved. His
> E-mail address is easy to find.
We can easily test that proposition. If I open the 5th edition at some
point (it turned out to be page 60) and start commenting on what I
find:-
| Page 61; Table of JavaScript operators:-
|
| Operator Operand type(s) Operation performed
| -----------------------------------------------------------
| . object, identifier Property access
| [] array, integer Array index
| () function, arguments function call
| new constructor call Create new object
| ++ lvlaue Pre-or post-increment(unary)
| -- lvalue Pre- or post-decrement(unary)
| - number unary minus(negation)
| + number Unary plus(no-op)
| ~ integer Bitwise complement(unary)
| ! boolean Logical complement(unary)
| delete lvalue Undefined a property(unary)
| typeof any Return datatype(unary)
|
| ...
|
| instanceof object, constructor Check object type
| in string, object Check whether property exists
|
| ...
|
| && boolean Logical AND
| || boolean Logical OR
| ...
The operands for the square brackets are object and string not array and
integer, and the operation is property access. The above serves to fuel
a common misconception that does not act to assist people learning
javascript to understand what they are doing.
The grouping operator is absent for the list (parenthesised
expressions).
Unary plus should not be ladled "no-op" as its type-converting side
effects are the main reason for using it at all. That makes listing the
operand types as 'number' a questionable act. Indeed, it could easily be
argued that most of the types shown should actually be 'any', as very
few operators are insistent on the actual type of their operands in
javascript. The two logical operators being probably the worst offenders
as examples of inappropriately labelled operand types (the right hand
side operand is never type converted by a logical AND or OR operation).
Javascript has no integer types, but if the intention is to express the
types that operands will be converted into then the assertion should be
signed or unsinged (as appropriate) 32 bit integers, as javascript's
numeric type can accommodate integers over a much greater range.
The action of the - delete - operator should not be labelled "Undefined
a property" as that is not what it does. If you delete a property of an
object and that object's prototype has an identically named property the
original object still effectively has the property 'defined', it just
does not actually have the property itself. It would be sufficient to
say that the - delete - operator removes a property from a specific
object, or attempts to, as it may not always succeed in the attempt.
The - typeof - operator does not return a "datatype" it returns a string
(if "returns" is going to be used to stand in for "evaluates as" at
all).
The listed operands of - instanceof - should be object (or, more
correctly 'any') and function, as those are the real restrictions on the
operation. And the operation should not be misleadingly described as
"Check object type" given that objects don't have types in this sense
and the object/function relationships tested by - instanceof - are
amenable to dynamic manipulation at runtime anyway, making the outcomes
potentially inconsistent over time and uncertain (neither of which fit
at all well with the concept of an object's type).
| Page 62:-
|
| For example it is not possible to multiply strings, so the
| expression "a" * "b" is not legal in JavaScript.
- which is simply not true. It is possible to multiply strings (at least
it is possible for strings to be the operands of the multiplication
operator, if often not meaningful), and the expression is completely
legal in JavaScript, just of extremely questionable worth.
| Page 63:-
|
| Notice that the assignment operators, as well as a few others
| operators, expect their left-side arguments to be lvalues.
| lvalue is a historical term that means "an expression that can
| legally appear on the left side of an assignment expression." In
| JavaScript, variables properties of objects, and elements of
| arrays are lvalues. The ECMAScript specification allows built-in
| functions to return lvalues but does not define any built-in
| functions that behave that way,
An example of imprecise wording. In context an "lvalue" is whatever
David Flanagan chooses to assert it to be. The concept being ladled is
what ECMA 262 names a "Reference type". The advantage of calling it a
Reference type is that anyone can go to the specification, look it up,
and then know precisely what it is that is being talked about.
So where the above says "variables, properties of objects and elements
of arrays" the fact that both the scope chain resolution of Identifiers
and property accessors result in reference types (always and only)
explains why these things may be the left has side of assignment
operations.
It also shows a factual omission, as grouping operations (parenthesised
expressions) may also be the left hand side of an assignment, whenever
the expression they contain evaluates as a Reference type. It would also
be practical to argue that if "variables" are to be included in the list
then (the Identifiers for) formal parameters and inner function
declarations may also be the left hand side of assignments.
"Variables, properties of objects and elements of arrays" are, of
course, all just properties of objects, making two items in that list
superfluous. In terms of explaining the language it may be acceptable to
include "variables" (and even use it as a shorthand for all Identifier
resolution, including inner function declarations and formal parameters)
but trying to enforce a distinction between properties of objects and
array elements is another manifestation of the error in the table of
operators on page 61 where bracket notation is misleadingly being
associated with array objects only.
Built-in functions (as defined in ECMA 262, section 4.3.7) may not
return a Reference type. The possibility that a function/method call
could return a Reference type is reserved for host objects (Section
4.3.8), as is stated in Sections 8.7 and 11.2.3.
Now that is 600 words on just 4 pages. The book is 950 odd pages long,
and that adds up to a lot of words and a lot of work writing them. If I
am going to put that much effort into doing something for free I am
going to do it where I have always prefer to do it. Right here on this
group, in public, and not some private e-mail exchange where nobody else
gets to comment on (or learn from) the exchange. If David Flanagan wants
his ideas and his code critiqued he is at liberty to bring them here and
present them to group as a whole, just like everyone else.
> But, as regards the FAQ, that's a detail.
>
> The FAQ maintainer seems to have wanted to say something
> equivalent to "The book ... is strongly endorsed by all
> experts in this newsgroup, being (when read in conjunction
> with its Errata) near enough perfectly accurate" - and
> cannot find anything to replace the ellipsis.
Are you saying that you have deduced that from something Randy has
written? That would not be my interpretation of his posts on the
subject. Though I am sure everyone would like to be in a position to be
recommending a book because it was "perfectly accurate" or in some other
sense good.
> But that's not what the intended reader needs; all he needs
> is something like "One of the best books is ..." - and that
> ellipsis *is* replaceable.
<snip>
But even that is misleading when a book gets to be "one of the best" by
virtue of being the least bad.
Richard.
dhtmlk...@gmail.com
>
> Built-in functions (as defined in ECMA 262, section 4.3.7) may not
> return a Reference type. The possibility that a function/method call
> could return a Reference type is reserved for host objects (Section
> 4.3.8), as is stated in Sections 8.7 and 11.2.3.
>
> Now that is 600 words on just 4 pages. The book is 950 odd pages long,
> and that adds up to a lot of words and a lot of work writing them. If I
> am going to put that much effort into doing something for free I am
> going to do it where I have always prefer to do it. Right here on this
> group, in public, and not some private e-mail exchange where nobody else
> gets to comment on (or learn from) the exchange. If David Flanagan wants
> his ideas and his code critiqued he is at liberty to bring them here and
> present them to group as a whole, just like everyone else.
>
The ecma262 manual is intended to be read by implementors. There is no
user guide.
Making a user-friendly manual for javascript (and it's variants) would
be a huge benefit to the community.
That would be awesome! David, where are you?
dfla...@gmail.com
Allow me to weigh in here on my book.
1) Thanks for the continued listing of the book in the FAQ. I
appreciate the listing, even if it is only a citation as, as Richard
would have it, "the least bad" book. Though I do like to believe that
there are lots of good parts in the book, too :-)
2) I don't believe that a link to my blog is appropriate. Recently
I've been blogging about Ruby the most, and also Java, with little
JavaScript content. I do think that, for purposes of identification,
it would be valuable to link my name to my website (which happens to
be a blog). That way I won't be mistaken for the conservative
political blogger, for example, who shares my name.
3) The JavaScript pocket reference is probably out of date, and while
I appreciate the listing, you might consider removing that link.
(Though the regular readers of this group might have a more well-
informed opinion about whether it is still a useful work.)
4) Richard: thank you for your feedback but please keep in mind that
my book is not intended to replace the specification. You appear to
be an expert who can read and learn things from the spec. The table of
operators you have critiqued remains from early editions of the book,
and I've never been quite satisfied with it. You make a number of good
points about it. Many of the points you raise cannot be addressed in
tabular form, however. And some of the points you raise are judgment
calls in which I have made a different judgment than you. For
example, I don't consider parentheses used for grouping to be
operators, so I didn't include them in the table.
5) David Golightly cites the list of technical reviewers for my 5th
edition. It is an impressive list, and I was very happy to have such
luminaries review the book. Nevertheless, the fact that they agreed
to do a technical review cannot be taken as their endorsement of the
book. Brendan Eich did offer an endorsement of the first or second
edition of the book, and that endorsement still appears on the back
cover.
Sincerely,
David Flanagan
Dr J R Stockton
, Mon, 3 Sep 2007 01:57:03, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>Dr J R Stockton wrote:
>> Richard Cornford posted:
>>>
>>> That was a real and demonstrable issue with Flanagan's book,
>>> and I can find plenty more of them, and back them up with
>>> reasoned argument and practical demonstration.
>>
>>
>> To be constructive, you could do that, and send it to David
>> Flanagan so that the Sixth Edition could be improved. His
>> E-mail address is easy to find.
>
>We can easily test that proposition. If I open the 5th edition at some
>point (it turned out to be page 60) and start commenting on what I
>find:-
>| Page 61; Table of JavaScript operators:-
>| ... ...
Waste of space; there is no doubt that you could and would comment at
length. That is of no use unless DF reads it. As a failed FAQ
maintainer, it ill behoves you to be over-critical of a successful
author.
>> But, as regards the FAQ, that's a detail.
>>
>> The FAQ maintainer seems to have wanted to say something
>> equivalent to "The book ... is strongly endorsed by all
>> experts in this newsgroup, being (when read in conjunction
>> with its Errata) near enough perfectly accurate" - and
>> cannot find anything to replace the ellipsis.
>
>Are you saying that you have deduced that from something Randy has
>written?
Since I know RW only by his writing, that must necessarily be the case.
> That would not be my interpretation of his posts on the subject.
And that can be equally true.
>Though I am sure everyone would like to be in a position to be
>recommending a book because it was "perfectly accurate" or in some
>other sense good.
That's why I thought RW would like to do so.
>> But that's not what the intended reader needs; all he needs
>> is something like "One of the best books is ..." - and that
>> ellipsis *is* replaceable.
>But even that is misleading when a book gets to be "one of the best" by
>virtue of being the least bad.
Do not compare the benefits of using Flanagan with the benefits of using
the book that you might have written; compare it with the benefits of
using no book.
But I wrote, and you quoted, "something like". You might prefer "One of
the less bad ..."
Richard Cornford
>>
>> Built-in functions (as defined in ECMA 262, section 4.3.7) may
>> not return a Reference type. The possibility that a
>> function/method call could return a Reference type is reserved
>> for host objects (Section 4.3.8), as is stated in Sections 8.7
>> and 11.2.3.
>>
> Can you explain why this is?
No. I can tell you why programmer defined functions cannot ever return a
reference type, but if you want to know why the specification only
admits that possibility for host objects you would have to ask its
authors. It seems an arbitrary decision, but not an unreasonable one.
>> Now that is 600 words on just 4 pages. The book is 950 odd
>> pages long, and that adds up to a lot of words and a lot of
>> work writing them. If I am going to put that much effort into
>> doing something for free I am going to do it where I have always
>> prefer to do it. Right here on this group, in public, and not
>> some private e-mail exchange where nobody else gets to comment
>> on (or learn from) the exchange. If David Flanagan wants his
>> ideas and his code critiqued he is at liberty to bring them
>> here and present them to group as a whole, just like everyone
>> else.
>>
>
> The ecma262 manual
It is not a manual, it is a specification.
> is intended to be read by implementors.
Yes it is, but not exclusively. Anyone wanting to understand the
behaviour of the language would be well advised to read the
specification that dictates that behaviour.
> There is no user guide.
Not explicitly for ECMAScript. There are JavaScript(tm) user guides. But
then programming languages don't really have 'users', the people using a
programming language either are programmers or have a very unrealistic
attitude towards what they are doing.
"User" is a term better reserved for the unfortunate individuals on the
receiving end of the things created by programmers. That is place where
letting 'user friendly' become synonymous with 'idiot friendly' isn't
necessarily such a bad idea.
> Making a user-friendly manual for javascript (and it's variants)
> would be a huge benefit to the community.
<snip>
Which community would that be?
Richard.
Richard Cornford
> Allow me to weigh in here on my book.
>
> 1) Thanks for the continued listing of the book in the FAQ.
> I appreciate the listing, even if it is only a citation as,
> as Richard would have it, "the least bad" book.
I usually write, "the least bad javascript book by a very large margin",
which is precisely what I think of the book. The completion is so bad
that if a book on javascript is wanted/needed then the definitive guide
is the only real candidate to be that book (even given my extensive
reservations about the book). And I can certainly appreciate that books
will be wanted; to be able to read from paper, read in bed, outside, on
the train, and so on. Portable computers may eventually rival books in
their versatility but they are not even close yet.
> Though I do like to believe that
> there are lots of good parts in the book, too :-)
There are.
> 2) I don't believe that a link to my blog is appropriate.
> Recently I've been blogging about Ruby the most, and also
> Java, with little JavaScript content. I do think that,
> for purposes of identification, it would be valuable to
> link my name to my website (which happens to be a blog).
> That way I won't be mistaken for the conservative
> political blogger, for example, who shares my name.
That my not be too practical at present. While HTML allows a name to
link to a web site the FAQ is also posted to the group in text form. In
order to avoid having to versions (with all the problems of keeping two
versions up to date in parallel) the actual FAQ is an XML file that can
be transformed into HTML or text. Currently the XML does not have
facilities to allow contained text to be presented as links in HTML and
differently presented in text format. Such changes to the XML have been
proposed but acting on them also means re-coding the various scripts
that use the existing XML so it is not a step that can be taken lightly.
> 3) The JavaScript pocket reference is probably out of date,
> and while I appreciate the listing, you might consider
> removing that link. (Though the regular readers of this
> group might have a more well- informed opinion about
> whether it is still a useful work.)
There never was that much support for the idea of including it in the
first place.
> 4) Richard: thank you for your feedback but please keep in
> mind that my book is not intended to replace the specification.
But also, I assume, not intended to contradict the specification.
> You appear to be an expert who can read and learn things
> from the spec.
If so, then only through making the effort to do so. The specification
is undoubtedly an obscure document that takes time and work to
understand. Other sources can tell you how things work in javascript,
but the specification can tell you _why_ they behave that way,
precisely. For example, it is easy to say that with -
someFunction(anObjecct.someMethod) - if - someFunction - calls its
argument directly the - this - value inside the call to that function
will never be - anObject -, but the things that makes that statement a
certainty are step 2 in the 3rd algorithm and step 3 in the 4th, in
section 11.2.4 of ECMA 262, 3rd Ed.
The 'whys' of the language's behaviour dictate its possibilities, and
perceiving the possibilities on offer is a pre-request for fully
exploiting the language.
The specification also provides an unambiguous set of terminology for
use when talking about javascript. It is very easy for anyone who wants
to throw any terms they like into a discussion of javascript; 'stack
frames', 'scope blocks', 'call objects', 'lvalues', 'execution
contexts', and so on. And of those terms only statements about
javascript employing only 'execution context' could be judged true or
false by anyone, because it is a term that is from the languages
specification and its role in the language has a precise definition. The
other terms may be used with intended meaning, under some unstated
misconception or in a deliberate attempt to impress the uninformed with
jargonise. All become possible because in relation to javascript the are
inherently ambiguous terms.
> The table of operators you have critiqued remains from early
> editions of the book, and I've never been quite satisfied with it.
As does the division of the book into 'core' and 'client-side'
javascript.
> You make a number of good points about it. Many of the points
> you raise cannot be addressed in tabular form, however.
So maybe some of the assertions do not belong in the table at all. The
details I did not show, the precedence, the order of operand evaluation
(rtl or ltr), plus categorisations such as 'unary', 'binary', etc. make
sense in a table, others could maybe be left until the explanatory text
for the operator.
And it is an absolute mistake to be labelling bracket notation property
accessors as 'array indexing' (and to repeat and re-enforce that
misconception throughout the rest of the book). It is no coincidence
that the FAQ has to explicitly re-enforce the property accessing role of
bracket notation. The harmful consequences of the misconception you
promote have dogged this group for longer than I have been writing
javascript.
Javascript has no Array-specific language syntax apart from array
literals. Bracket notation property accessors are only used to access
array elements to the exclusion of dot notation because an 'array index'
can never qualify as an Identifier and so cannot follow the dot in a dot
notation property accessor.
> And some of the points you raise are judgment
> calls in which I have made a different judgment than you.
> For example, I don't consider parentheses used for grouping
> to be operators, so I didn't include them in the table.
<snip>
Listing the grouping operator as an operator is a matter of judgment.
The specification categorises it as such, but thinking about
parenthesising (sub)expressions as using an operator is not going to
contribute anything much to learning a programming language.
The other points I made are much less a matter of judgment. It is in the
nature of programming languages to be consistent, and to be precise. It
should be expected that an explanation of a programming language also be
consistent, preferably be precise and certainly be factual.
Richard.
dhtmlk...@gmail.com
wrote:
If I wrote a class and published it, other developers could use my
code; they'd be the users.
When I write a program that runs in a web browser, I am using
javascript. When I am called by a recruiter, they will ask me: "Do you
use [insert_programming_language_here]?"
> > Making a user-friendly manual for javascript (and it's variants)
> > would be a huge benefit to the community.
>
> <snip>
>
> Which community would that be?
>
web-developers/javascript developer community.
> Richard.
dhtmlk...@gmail.com
Awesome that you could drop in and comment. Definitely plenty of good
parts in your book. There is good reason that it's the most highly
regarded/endorsed JavaScript book in existence.
I know you're busy with Ruby and real world stuff as well, but I feel
strongly about this issue
ECMA 262 needs a user manual.
Java has one; it's called the JLS (Java Language Specification). It's
easier to read than the ECMA 262 spec.
If ECMAScript had a manual full of examples, there would be a lot less
confusion among us javascript developers; it would be easier to clear
up confusion/misunderstanding. We'd all be able to scream at
implementations when they we're wrong.
The lack of a manual for JavaScript is the largest reason that
JavaScript is "the world's most misunderstood programming language."
Here's another quote from Doug's website:
"...
Substandard Standard
The official specification for the language is published by ECMA. The
specification is of extremely poor quality. It is difficult to read
and very difficult to understand. This has been a contributor to the
Bad Book problem because authors have been unable to use the standard
document to improve their own understanding of the language. ECMA and
the TC39 committee should be deeply embarrassed.
..."
I don't agree with Doug on all things, but this is one thing that I do
agree on, and strongly. We all know Doug knows JavaScript.
There should be an official manual.
Garrett
FAQEditor
> Hi All,
>
> Allow me to weigh in here on my book.
>
> 1) Thanks for the continued listing of the book in the FAQ. I
> appreciate the listing, even if it is only a citation as, as Richard
> would have it, "the least bad" book. Though I do like to believe that
> there are lots of good parts in the book, too :-)
You can please some of the people all of the time.
You can please all of the people some of the time.
You can't please all of the people all of the time :)
As for the FAQ Entry, I don't see your book coming out of it any time in
the near future.
> 2) I don't believe that a link to my blog is appropriate. Recently
> I've been blogging about Ruby the most, and also Java, with little
> JavaScript content. I do think that, for purposes of identification,
> it would be valuable to link my name to my website (which happens to
> be a blog). That way I won't be mistaken for the conservative
> political blogger, for example, who shares my name.
If I remember right, when the blog address was added you were blogging
about the book. The link to it has been removed from my local copy and
will be removed from the online copy of the FAQ sometime this week.
> 3) The JavaScript pocket reference is probably out of date, and while
> I appreciate the listing, you might consider removing that link.
> (Though the regular readers of this group might have a more well-
> informed opinion about whether it is still a useful work.)
Nothing quite like an author suggesting you not recommend his own book.
The reference to it has been removed locally and will also get removed
this week from the online version.
Richard Cornford
> On Sep 3, 5:13 pm, Richard Cornford wrote:
>> <dhtmlkitc...@gmail.com> wrote:
<snip>
>>> The ecma262 manual
>>
>> It is not a manual, it is a specification.
>>
>>> is intended to be read by implementors.
>>
>> Yes it is, but not exclusively. Anyone wanting to understand
>> the behaviour of the language would be well advised to read
>> the specification that dictates that behaviour.
>>
>>> There is no user guide.
>>
>> Not explicitly for ECMAScript. There are JavaScript(tm) user
>> guides. But then programming languages don't really have 'users',
>> the people using a programming language either are programmers
>> or have a very unrealistic attitude towards what they are doing.
>>
>> "User" is a term better reserved for the unfortunate individuals
>> on the receiving end of the things created by programmers. That
>> is place where letting 'user friendly' become synonymous with
>> 'idiot friendly' isn't necessarily such a bad idea.
>>
> User can mean more than one thing.
Most terms can mean more than one thing, but it is useful for
communication if they are used to mean a specific thing in particular
contexts. Programmers and users have a particular, and important
relationship. So it is not a good idea to attach the label 'user' to
both parties in that relationship.
> Don't misinterpret.
Avoid being ambiguous and I will not have the opportunity.
> If I wrote a class and published it, other developers could
> use my code; they'd be the users.
If by 'class' you mean some structure defined in javascript source code
then the only way in which they could 'use' it would be in writing a
computer program, and the person writing a computer program is a
programmer, whether they like it or not.
> When I write a program that runs in a web browser, I am
> using javascript.
And you are also then a person engaging in programming; a programmer.
> When I am called by a recruiter, they will ask me:
> "Do you use [insert_programming_language_here]?"
Seems unlikely. The question "do you know
[insert_programming_language_here]?" would be more reasonable.
>>> Making a user-friendly manual for javascript (and it's
>>> variants) would be a huge benefit to the community.
>>
>> <snip>
>>
>> Which community would that be?
>>
> web-developers/javascript developer community.
<snip>
So that would be a purely rhetorical "community", as significant as
talking of 'a hat wearing community'.
It would be trivial to argue that anything that made learning javascript
easier would act to harm such a rhetorical community; In a free market
economy supply and demand relationships influence pricing. If the supply
of javascript programmers is less than the demand for javascript
programmers the remuneration they can achieve (on average) will rise. If
the supply of javascript programmers rises, and particularly if it rises
to exceed the demand for them, their average remuneration will fall.
Your community will suffer if all of its individual members experience a
relative fall in their income.
It may be the case that individuals who what to learn javascript, or
better understand it, may benefit form having access to better sources
of information. More is not necessarily the same as better, and as many
web-based javascript (indeed web development in general) 'tutorials'
demonstrate, sometimes nothing would be better than what is available
(as that would avoid people having to unlearn what they thought they had
learnt from other people's misconceptions and bad practices).
Richard.
FAQEditor
> In comp.lang.javascript message <fbd94a$p05$1$8300...@news.demon.co.uk>
> , Sun, 2 Sep 2007 04:02:44, Richard Cornford
> <Ric...@litotes.demon.co.uk> posted:
>> That was a real and demonstrable issue with Flanagan's book, and I can
>> find plenty more of them, and back them up with reasoned argument and
>> practical demonstration.
>
>
> To be constructive, you could do that, and send it to David Flanagan so
> that the Sixth Edition could be improved. His E-mail address is easy to
> find.
>
>
> But, as regards the FAQ, that's a detail.
As regards the FAQ, the entry is staying the way it is for now.
> The FAQ maintainer seems to have wanted to say something equivalent to
> "The book ... is strongly endorsed by all experts in this newsgroup,
> being (when read in conjunction with its Errata) near enough perfectly
> accurate" - and cannot find anything to replace the ellipsis.
Contrary to what you may think, may want to think, believe or want to
believe, I wrote exactly what I meant to write. And nothing you think
that I "seem to have wanted to say" will change it. Nor is there an
ellipsis in what I wrote.
Randy Webb
> In comp.lang.javascript message <fbfm4v$c10$1$8300...@news.demon.co.uk>
> , Mon, 3 Sep 2007 01:57:03, Richard Cornford
> <Ric...@litotes.demon.co.uk> posted:
>> Dr J R Stockton wrote:
>>> Richard Cornford posted:
>>>> That was a real and demonstrable issue with Flanagan's book,
>>>> and I can find plenty more of them, and back them up with
>>>> reasoned argument and practical demonstration.
>>>
>>> To be constructive, you could do that, and send it to David
>>> Flanagan so that the Sixth Edition could be improved. His
>>> E-mail address is easy to find.
>> We can easily test that proposition. If I open the 5th edition at some
>> point (it turned out to be page 60) and start commenting on what I
>> find:-
>
>> | Page 61; Table of JavaScript operators:-
>> | ... ...
> Waste of space; there is no doubt that you could and would comment at
> length. That is of no use unless DF reads it. As a failed FAQ
> maintainer, it ill behoves you to be over-critical of a successful
> author.
YSCIB. And, Richard is not a "failed FAQ maintainer" as you like to
throw around. Richard did more for the FAQ in the time I he maintained
it than you have done in your entire time in c.l.j. And, no matter how
many times you write it, it won't make it true.
>>> But, as regards the FAQ, that's a detail.
>>>
>>> The FAQ maintainer seems to have wanted to say something
>>> equivalent to "The book ... is strongly endorsed by all
>>> experts in this newsgroup, being (when read in conjunction
>>> with its Errata) near enough perfectly accurate" - and
>>> cannot find anything to replace the ellipsis.
>> Are you saying that you have deduced that from something Randy has
>> written?
>
> Since I know RW only by his writing, that must necessarily be the case.
Your powers of deduction are flawed then. All it takes is to read what I
write and comprehend it to know exactly what I meant and wrote. From
your past posts, it is obvious that you fail to understand what I write
and mean by what I write.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Richard Cornford
> References: <Cq6dnclPf6l...@giganews.com>
> <fbcc7i$sqs$1$8300...@news.demon.co.uk>
> <1188677590.9...@k79g2000hse.googlegroups.com>
<snip>
> <1188854861.2...@o80g2000hse.googlegroups.com>
> <fbi7vh$51u$1$8300...@news.demon.co.uk>
> In-Reply-To: fbi7vh$51u$1$8300...@news.demon.co.uk
>
> David,
<snip>
Why have you posted a message that appears to be intended as a response
to David Flanagan as a reply to my message (Message-ID:
<fbi7vh$51u$1$8300...@news.demon.co.uk>)?
Richard.
dfla...@gmail.com
On Sep 3, 5:13 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
> The specification also provides an unambiguous set of terminology for
> use when talking about javascript. It is very easy for anyone who wants
> to throw any terms they like into a discussion of javascript; 'stack
> frames', 'scope blocks', 'call objects', 'lvalues', 'execution
> contexts', and so on. And of those terms only statements about
> javascript employing only 'execution context' could be judged true or
> false by anyone, because it is a term that is from the languages
> specification and its role in the language has a precise definition. The
> other terms may be used with intended meaning, under some unstated
> misconception or in a deliberate attempt to impress the uninformed with
> jargonise. All become possible because in relation to javascript the are
> inherently ambiguous terms.
Respectfully, I disagree. Had the spec been better written, book
authors like myself could use the terminology from the spec. It was a
conscious choice to use terms other than those from the spec, but it
is a choice I stand by
> > The table of operators you have critiqued remains from early
> > editions of the book, and I've never been quite satisfied with it.
>
> As does the division of the book into 'core' and 'client-side'
> javascript.
This is also a decision I stand by strongly. The core language is
formally specified and can be used outside of browsers, such as to
script Java 6. The client-side portion is clearly distinct and I
think it ought to be covered separately. The 4th edition introduced a
distinction between traditional client-side JavaScript and the DOM.
That distinction ceased to be relevant and those two sections have
been re-integrated in the 5th edition.
David
Dr J R Stockton
oglegroups.com>, Mon, 3 Sep 2007 14:27:41, dfla...@gmail.com posted:
Good to see you here.
> That way I won't be mistaken for the conservative
>political blogger, for example, who shares my name.
I have similar feelings about a basketballer of Utah.
>3) The JavaScript pocket reference is probably out of date, and while
>I appreciate the listing, you might consider removing that link.
>(Though the regular readers of this group might have a more well-
>informed opinion about whether it is still a useful work.)
For the purpose of placing and keeping immediately to hand on a crowded
desk, it is enormously better than The Definitive Guide. There does not
seem to be much wrong with the Pocket 2nd Edn, as long as one remembers
its date.
In Date, there should be a mention of 1970-01-01 00:00:00 UT as the
origin of getTime, setTime, valueOf, new Date(milliseconds); get[UTC]Day
needs (Sun=0 to Sat=6); getTimezoneOffset needs minutes and East or
West; (get|set)[UTC]month needs (0 to 11) ; all IMHO. Probably you have
them in the Definitive.
Page 12 lacks, I suspect, an entry for delete.
A list of the methods using RegExps could help those who have trouble
remembering whether, for example, match belongs to String or RegExp (so
I made my own list [@ <http://www.merlyn.demon.co.uk/js-valid.htm#JS>]).
I'd like to buy a 3rd edition of it, especially at a UK price
recognising the $:£ ratio.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Richard Cornford
> On Sep 3, 5:13 pm, Richard Cornford wrote:
>> The specification also provides an unambiguous set of terminology
>> for use when talking about javascript. It is very easy for anyone
>> who wants to throw any terms they like into a discussion of
>> javascript; 'stack frames', 'scope blocks', 'call objects',
>> 'lvalues', 'execution contexts', and so on. And of those terms
>> only statements about javascript employing only 'execution context'
>> could be judged true or false by anyone, because it is a term that
>> is from the languages specification and its role in the language
>> has a precise definition. The other terms may be used with
>> intended meaning, under some unstated misconception or in a
>> deliberate attempt to impress the uninformed with jargonise.
>> All become possible because in relation to javascript the are
>> inherently ambiguous terms.
>
> Respectfully, I disagree.
I expected that you would.
> Had the spec been better written, book authors like myself
> could use the terminology from the spec.
That isn't much of an excuse. Had the spec been differently written it
might have been the starting point for learning javascript as a language
instead of the ending point. As it is the spec is no more than it needs
to be on order to do its job (and very slightly less in a few areas),
but that doesn't stop it from providing terminology that becomes
unambiguous by virtue of its existence as a common and precise reference
point.
> It was a conscious choice to use terms other than those from
> the spec, but it is a choice I stand by
But when you feel at liberty to make up your own terminology others may
see justification for doing likewise. So, for example, when we read:-
"It would seem that x would be a new variable in a scope block, but with
doesn't create a scope block, it instead conflates the current scope
block."
- from a recent post this group, are we seeing a factual (or
alternatively, a false) statement about javascript, a manifestation of a
misconception or maybe even deliberate BS? It all hangs on whatever
"scope block" is intended to label.
If a "scope block" is intended to directly label a single object on the
scope chain then it is a statement that directly relates to javascript
(and is a false statement as the - with - statement acts to add a single
object to the scope chain, and so in the terminology proposed to apply
does 'create a scope block').
Alternatively "scope block" may be a manifestation of the misconception
common in people who (have just) come to javascript from Java and assume
that javascript will be block scoped just like Java. And so an
individual who could benefit form an explanation of how the units of
scoping work in javascript in order that they can avoid repeating their
mistake.
Then again it might be a statement made by someone with their own (more
or (more often) less) self-consistent fantasy explanation of javascript,
in which a 'scope block' is some fictional entity that is amenable to
being conflated (literally: 'blown together'). Obviously, being utterly
detached from the reality of javascript, such a statement can contribute
nothing to anybody's understanding of the language.
And then there is the possibility that it is just a statement made by
someone who has become used to bullshiting their way past others,
concealing their ignorance behind a wall of meaningless (pseudo)
technical jargon. There is no truth, falsity, misconception or fantasy
in the statement, just some hollow attempt at deception.
So what happens? Someone posts a reply saying that "scope block" has no
meaning and asks for clarification and we wait for a response. And if no
response if forthcoming there the statement sits, in the archives,
another hurdle for those seeking an understand of javascript to stumble
over on there journey, and another addition to the mass of nonsense
already written about javascript.
>>> The table of operators you have critiqued remains from early
>>> editions of the book, and I've never been quite satisfied
>>> with it.
>>
>> As does the division of the book into 'core' and 'client-side'
>> javascript.
>
> This is also a decision I stand by strongly. The core language
> is formally specified and can be used outside of browsers,
> such as to script Java 6. The client-side portion is clearly
> distinct and I think it ought to be covered separately.
<snip>
It should be covered separately, but my point is that 'client-side
javascript' is not javascript (how could it be if javascript can be used
in isolation from it?). What you have is a distinction between
javascript as a language and a host environment which it is used to
script; a web browser host. Documenting that host (even as
inconsistently/irrationally as you do it) is important/vial but there is
no reason to let anyone get the mistaken impression that what you are
documenting is javascript ('client-side' or otherwise) when it is not.
Richard.
Dr J R Stockton
glegroups.com>, Tue, 4 Sep 2007 09:52:30, dfla...@gmail.com posted:
> The 4th edition introduced a
>distinction between traditional client-side JavaScript and the DOM.
>That distinction ceased to be relevant and those two sections have
>been re-integrated in the 5th edition.
Is that cessation altogether true? Surely javascript executed in
Windows Scripting Host does not share the browser DOM? Some WSH tasks,
at least, are easier in javascript.
--
dhtmlk...@gmail.com
wrote:
> <dhtmlkitc...@gmail.com> wrote:
> > References: <Cq6dnclPf6lJHkXb4p2d...@giganews.com>
> > <fbcc7i$sqs$1$8300d...@news.demon.co.uk>
> > <1188677590.971881.225...@k79g2000hse.googlegroups.com>
> <snip>
> > <1188854861.206995.151...@o80g2000hse.googlegroups.com>
> > <fbi7vh$51u$1$8300d...@news.demon.co.uk>
> > In-Reply-To: fbi7vh$51u$1$8300d...@news.demon.co.uk
>
> > David,
>
> <snip>
>
> Why have you posted a message that appears to be intended as a response
> to David Flanagan as a reply to my message (Message-ID:
>
As I was writing, I realized some things; I changed my response, as
talking about the word "use" seemed not as important as my other
point, so I dropped it, continued writing, and hit 'reply', using the
same textarea.
I use google groups UI so I don't see the headers you see. I chose
Groups' heavy, buggy, UI over trying to the digest mails. However,
groups UI has failed me again by disabling the submit button and not
enabling it when the call fails. I have to find a better way to deal w/
digest mails.
Regardless...
Directly emailing David would have been constructive; he might have
even given you props.
Moving on to a real question...
If a book is opened to a certain page a lot, or if it is laid open or
folded open, as if to facilitate extended reading, then the book will
more easily open to that page. My question is regarding the page that
you opened the book up to "at some point" (pg 60). Was pg 60 a page
that you had read thoroughly and pessimistically?
Garrett
> Richard.
Thomas 'PointedEars' Lahn
> If a book is opened to a certain page a lot, or if it is laid open or
> folded open, as if to facilitate extended reading, then the book will
> more easily open to that page. My question is regarding the page that
> you opened the book up to "at some point" (pg 60). Was pg 60 a page
> that you had read thoroughly and pessimistically?
If *you* would have read more thorough, you would have observed that
Richard commented on several, yet consecutive, pages. But your question is
irrelevant. Given that many misconceptions uncovered about the most basic
features of the language (implementation) the author has, had or just
transports to the uninitiated reader, do you really expect other pages
dealing with mu€ch more complicated matters that have to build on the
understanding of those basics to be of considerable better quality?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> On Sep 6, 2:05 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> dhtmlkitc...@gmail.com wrote:
>>> If a book is opened to a certain page a lot, or if it is laid open or
>>> folded open, as if to facilitate extended reading, then the book will
>>> more easily open to that page. My question is regarding the page that
>>> you opened the book up to "at some point" (pg 60). Was pg 60 a page
>>> that you had read thoroughly and pessimistically?
>> If *you* would have read more thorough, you would have observed that
>> Richard commented on several, yet consecutive, pages. But your question is
>> irrelevant.
>
> question."
But I didn't. That was not to insult anyone but merely to state the fact.
Whether or not Richard opened that book on that page deliberately does not
matter, so your question (talking about insults, rather your subtle
insinuation of him lying about how he got to that page) is very irrelevant.
You may not like that, but there it is.
> Given that many misconceptions uncovered about the most basic
>> features of the language (implementation) the author has, had or just
>> transports to the uninitiated reader, do you really expect other pages
>> dealing with mu€ch more complicated matters that have to build on the
>> understanding of those basics to be of considerable better quality?
>>
> I'm reviewing David's book and am planning to email comments directly
> to him.
What would that accomplish?
> [...]
> I have some general feedback (opinion, not errata) that others may
> disagree with. I am posting it here so that others can comment on it.
> Here it is:
>
> This book should address cross-browser issues in scripting engines and
> host environments (at least the popular browsers).
With regard to script engines, cross-browser issues are irrelevant. With
regard to host (or rather execution) environments, which are for example Web
browsers, I concurred if that book was named "ECMAScript Implementations:
The Definitive Guide."
> There are differences between IE, FF, Opera, Safari. RegExp, FunctionExpression,
> iteration using for-in, Object-literal notation, to name a handful.
True. I have created http://PointedEars.de/scripts/es-matrix because of
that, and I am not finished yet (if I ever will be).
> For example:
> javascript:alert( { foo: 1, } )
>
> An error will be thrown in JScript, but not in FF.
That should read "JScript, but not JavaScript". FF is not a programming
language, it is an execution environment for the latter programming language.
> It is useful to know (where, how, why, what the spec says, which browser
> is wrong, how to avoid it, et c).
No browser or engine is wrong here, because the specification explicitly
allows such deviations for conforming implementations per its Conformance
section (which is IMHO one problem with the specification: it allows too
much deviation from it). In this case (and with Array literals) that
deviation can be handled easily by avoiding the trailing comma.
> Where such issues exist, they should be explained which browsers,
"Which browsers" can be easily covered by mentioning which browser (version)
implements which version of which language, and then explaining the features
of the language (version).
> why they exist (if known), what implications it has, how it deviates from
> the spec, and an example should be provided. This can also greatly
> benefit js programmers who can complain to the relevant vendors.
Non sequitur, see above.
> For example, surprisingly few people are aware that for-in iteration is
> broken in IE due to a faulty implementation of DontEnum.
Since I don't use for..in much, and don't write primarily for IE, IIRC
that has never occurred to me. Could you give an example, please?
> This is well-known among experts, but not everyone else.
Hmmm.
> I have seen many competent and intelligent programmers trip on this bug.
I haven't, and I am not exactly new to the topic or the industry.
> [...]
> I would like to encourage others to also submit feedback to David (his
> email address appears earlier in this thread).
Again, to what end? Given the Law of Knowledge[tm] I have proposed here
recently, would that not mean that there is much greater a chance that only
further misconceptions would enter into the book this way?
I agree with Richard here; it would be much better if comments on that book
would be posted here, so that they are seen by many eyes. That way,
everyone learned.
> There is a lot of knowledge in this group (and misinformation, too).
> If we can stop insulting each other, it could be a very productive way
> to share knowledge.
JFTR: I don't like personal attacks either (against anyone), and I try not
to post in that way.
But some people take everything personal, don't have or don't show that
basic sense of humor, and thus are easily pissed off by any comment they
receive. They really should not subscribe to or even post to a technical
group like this, because it's hard facts we are dealing with even when
it's only software. (You may quote me on that.)
> If this is a hostile place, I'm afraid David won't have much
> motivation to return. And he's not the only one.
I fail to see anything hostile in proving things to be wrong.
> The next version of the book will most likely have to cover ES4.
That should read "unlikely", trust me.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Richard Cornford
<snip>
> I'm reviewing David's book and am planning to email comments
> directly to him.
You don't see that as being of questionable usefulness, given that you
are a relative novice yourself? And although I am fairly sure that you
will be offended by that statement it is the case; it is not even two
months since it was necessary for me to point out to you that javascript
has both String objects and string primitive data types (Message-ID:
<f7635d$4al$1$8302...@news.demon.co.uk>) as a correction to your
apparent misconception that javascript strings where handled much like
Java String objects (and then there is the rest of the stuff on your web
site). It is amazing that javascript can tolerate so much productive
achievement while its authors labour under so many misconceptions about
its basics, but those 'achievements' do not then become testimony to
their author's understanding. It isn't personal, it is just factual.
> Sure, there are errors. Some of them are more offensive than
> others.
>
> The book is too comprehensive for one book, IMO. It would be
> better to have a language programmer's guide that the book could
> refer to. The book could then discuss the guide, providing host
> implementation specifics (bugs, et c).
>
> Writing a technical book is not an easy task. There are plenty of
> explanations backed by example.
>
> I have some general feedback (opinion, not errata) that others may
> disagree with. I am posting it here so that others can comment on
> it.
> Here it is:
>
> This book should address cross-browser issues in scripting
> engines and host environments (at least the popular browsers).
But "at least the popular browsers" is precisely the wrong approach to
take to cross browser issues. It results in implementations that branch,
add a branch for each browser added to the 'supported' set, and fail to
handle any browser encountered that are not known to the programmer
(which must be the bulk of actual browsers, particularly if they think
in terms of "popular browsers").
> There are
> differences between IE, FF, Opera, Safari.
And there always will be. There are also other browsers, now and in the
future. Go back five years and it was likely that most individuals where
not considering how Opera would handle anything (possibly as a result of
not being aware that it existed at all, or not seeing it as
significant). And Safari did not even exist then.
> RegExp, FunctionExpression,
> iteration using for-in, Object-literal notation,
> to name a handful.
>
> For example:
> javascript:alert( { foo: 1, } )
So in ECMAScript terms a syntax error.
> An error will be thrown
The author should be expecting an error to be thrown, and consider
him/herself lucky if that ever does not happen.
> in JScript, but not in FF.
So JavaScript(tm) (now) has a syntax extension that recognises that a
trailing comma in an object literal is not problematic and can be
disregarded as a correctable mistake. That is not an issue as the
knowledgeable author will not write code that includes the ECMAScript
syntax error, so how that error may be handled if made would not be an
issue at all.
> It is useful to know (where, how, why, what the spec says,
> which browser is wrong, how to avoid it, et c).
It is useful to know what the formal syntax is (as specified), and maybe
that errors will not (directly) result form using it, but going into
details about how some syntax errors may be error-corrected in some
environments seems pointless.
A more significant issue follows from the use of trailing commas in
Array literals, where the syntax is formally correct but suffers
incorrect interpretation in JScript.
<snip>
> For example, surprisingly few people are aware that for-in
> iteration is broken in IE due to a faulty implementation of
> DontEnum. This is well- known among experts,
Well, what is well known among experts is that when doing variable
instantiation in the global execution contexts JScript fails to mark the
properties added to global object by virtue of its being the Variable
object for that execution contexts with the - DontEnum - attribute (as
ECMA 262 says it should), and so they can be subsequently enumerated by
for-in loops. It is unlikely that they would use that knowledge to
declare for-in loops "broken" or attribute any consequences to "a faulty
implementation of DontEnum.
> but not everyone else. I have seen many competent and
> intelligent programmers trip on this bug.
That would be a matter of opinion. Designing a system that relied on
consistent for-in iteration of the properties of a host object would be
seriously misguided, and in web browser the global object always is a
host object in practice.
> If the book were to document things like this, fewer people
> would have that mistake.
Isn't that just saying that if you tell people things they may then know
those things?
> Programming should not be something based on lore knowledge of
> browser obscurities.
And this just after you have proposed the identification and
documentation of a huge body of precisely this "lore knowledge"?
> At it's best, programming is Art.
Others may prefer it be an engineering practice (though it is not that
either in reality).
<snip>
> There is a lot of knowledge in this group (and misinformation,
> too). If we can stop insulting each other, it could be a very
> productive way to share knowledge.
It already is a very productive place to share knowledge, and more
importantly a place where ideas can tested and challenged,
misconceptions and myths exposed and corrected and code
critiqued/improved , and all in public and by a group of individuals who
are anything but a gang of sycophantic hangers on.
> If this is a hostile place, I'm afraid David won't have
> much motivation to return. And he's not the only one.
<snip>
If someone's ego is too fragile to take reasoned criticism the let them
go off and hide (or find some small pond where they can be as big a fish
as they like without having to earn that position). Open, public debate
may not see much mutual backslapping but it is honest, and an idea that
cannot stand criticism is very unlikely to be a good idea.
Richard.
Richard Cornford
> On Sep 4, 6:24 am, Richard Cornford wrote:
<snip>
>> Why have you posted a message that appears to be intended
>> as a response to David Flanagan as a reply to my message
>> (Message-ID: <fbi7vh$51u$1$8300d...@news.demon.co.uk>)?
>>
> As I was writing, I realized some things;
Apparently not including who it was you were replying to.
<snip>
> I use google groups UI so I don't see the headers you see.
Under normal circumstances I do not see (most) headers, only their
consequences. If I want to know what they were I have to look at the
original message text, which can (more or less) also be done through
Google groups.
> I chose Groups' heavy, buggy, UI over trying to the digest
> mails.
That makes no sense. What "mails"?
> However, groups UI has failed me again ... .
Haven't you ever looked at the code on a Google groups page? It does not
take more than a cursory glance to realise with that anything created by
individuals who use javascript that ineptly regular failure should be
the expectation.
> I have to find a better way to deal w/
> digest mails.
Sentences tend to be more effective in communication if they are
constructed from words.
> Regardless...
>
> Directly emailing David would have been constructive;
Your replying to his post rather than mine would also have been more
constructive.
Or do you mean I should have emailed David Flanagan my comments on four
consecutive pages of his book? In which case you have failed to
comprehend that the point of post was not to criticise the book, but was
to test the practicality of the proposition that I should criticise the
book at a whole.
> he might have
> even given you props.
Given me "props"? Props; plural of Prop; "a ridged support; a
supplementary support; a stay; a strut; .... a tie-pin; a broach; ...
short form of: propeller; property; proposition; ... either of the two
forwards at the ends of the front row of the scrum (Rugby football)."
That seems a very odd proposition.
> Moving on to a real question...
>
> If a book is opened to a certain page a lot, or if it is laid
> open or folded open, as if to facilitate extended reading, then
> the book will more easily open to that page.
That is an 'if'. In practice my copy of the book is in mint condition
and does not fall open anywhere; if I hold the book by the front edge
and set its spine down on a desk it just falls over in one lump.
> My question is
> regarding the page that you opened the book up to "at some
> point" (pg 60). Was pg 60 a page that you had read thoroughly
> and pessimistically?
No, I would not be surprised if that wasn't the first time those
particular pages had been exposed to sunlight since I bought the book.
It would not have been a valid test of the proposition to have done
anything other than randomly select the page and then go with whatever I
found there.
Richard.
Richard Cornford
<snip>
>> For example, surprisingly few people are aware that for-in
>> iteration is broken in IE due to a faulty implementation of
>> DontEnum. This is well- known among experts,
>
> Well, what is well known among experts is that when doing variable
> instantiation in the global execution contexts JScript fails to
> mark the properties added to global object by virtue of its being
> the Variable object for that execution contexts with the - DontEnum
> - attribute (as ECMA 262 says it should), and so they can be
> subsequently enumerated by for-in loops.
Well, I got that the wrong way around. JScript's mistake is that it does
mark the properties with the - DontEnum - attribute when it should not,
so they will not be enumerated by for-in when that should be possible.
> It is unlikely that they would use that knowledge to declare for-in
> loops "broken" or attribute any consequences
> to "a faulty implementation of DontEnum.
<snip>
Richard.