What's a good Javascript book?

[I Am Here]

Hi,
Can someone recommend me a good book which will cover ALL important features of Javascript? I already have 3, but NONE of them, as I discovered to my downfall recently, covered for example, hashes, or how they are treated as objects.
I don't wish to go on my expertise alone, as it's failed me - I want some experts to recommend a book which will cover everything.

Thanks,
I Am Here.

[Evertjan.]

Most javascript books have been found to contain so many technical errors
that consensus recommendations have not emerged from the group.

<http://jibbering.com/faq/#books>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jukka K. Korpela]

2012-10-08 16:52, Evertjan. wrote:

> I Am Here wrote on 08 okt 2012 in comp.lang.javascript:
>
>> Can someone recommend me a good book which will cover ALL important
>> features of Javascript? I already have 3, but NONE of them, as I
>> discovered to my downfall recently, covered for example, hashes, or
>> how they are treated as objects. I don't wish to go on my expertise
>> alone, as it's failed me - I want some experts to recommend a book
>> which will cover everything.
>
> Most javascript books have been found to contain so many technical errors
> that consensus recommendations have not emerged from the group.
>
> <http://jibbering.com/faq/#books>

Right, but the dusty old FAQ is... er... dusty. E.g., "JavaScript: The
Definitive Guide" is now in 6th edition (2011) and contains good new
stuff, and hopefully has the known errata fixed.

I have little idea of what the OP means by hashes and which three books
he has got. But if he means that he would like to get a book that covers
everything, or at least everything that can be programmed in JavaScript,
I'm afraid he will need to wait for a few exaseconds.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Stefan Weiss]

On 2012-10-08 15:35, I Am Here wrote:
> Can someone recommend me a good book which will cover ALL important
> features of Javascript? I already have 3, but NONE of them, as I
> discovered to my downfall recently, covered for example, hashes, or how
> they are treated as objects.

There seems to be a conceptual misunderstanding here. ECMAScript has
objects but no concept of a "hash". (Objects may be implemented as some
form of hash table or hash map internally, but that's of no consequence
to users.)

Reading between the lines, could it be that you're confused by this
notation:

myObj["foo"] = 42;

That's exactly the same as writing

myObj.foo = 42;

Use the second form if the property name is known and a valid
identifier, use the first form if you're building the property name
dynamically, or for property names like "my-prop".

> I want some experts to recommend a book which will cover everything.

Good luck with that, especially in this group.

I would be immensely surprised if anybody here could recommend a book
that really "covers everything", if such a thing even exists. All of the
books I've seen, or read reviews of, are incomplete and inaccurate in
some way. But that doesn't make them useless. With a suitable
combination of imperfect books and some basic curiosity you'll be well
on your way. If you're still having trouble, you know where to ask :)

That said, Flanagan's "Definitive Guide" is one of the books I've seen
recommended most often. If this isn't one of your three books, give it a
try. BTW, mentioning which three books you already own would have been a
good idea.

- stefan

[Gregor Kofler]

Am 2012-10-08 15:35, schrieb I Am Here:
> Hi,
> Can someone recommend me a good book which will cover ALL important features of Javascript? I already have 3, but NONE of them, as I discovered to my downfall recently, covered for example, hashes, or how they are treated as objects.

Understandable, since there are no "hashes" in ES/JS.

> I don't wish to go on my expertise alone, as it's failed me - I want some experts to recommend a book which will cover everything.

What do you mean by "everything"? A complete coverage of JS/ES (then
which version?), or browser scripting in particular?

Gregor

> I Am Here.

Obviously.

[Mel Smith]

Tim said:

> Since as you two say there is no consensus, let me say I have two:
>
> JavaScript Bible 7th Edition, Goodman et al
> JavaScript The Definitive Guide 5th Edition
>
> Of these two, in practice I use the Bible and not the Guide almost
> entirely.

Hi:

I agree with Tim, and use the above two manuals in the same way.

My only difference is that I don't yet know what I'm doing :((

-Mel Smith
(surviving with the help of all you folks :) )

[Michael Haufe (TNO)]

I have high hopes for this:

http://effectivejs.com/

[Matt McDonald]

On 08/10/12 09:35, I Am Here wrote:

> Can someone recommend me a good book which will cover ALL important

> features of [JavaScript]?

There is no book that adequately covers JavaScript. Douglas
Crockford's *JavaScript: The Good Parts* contains a moderately high
level of technical depth, but is quite brief.

David Flanagan's *JavaScript: The Definitive Guide* is at best a
mediocre physical manifestation of Mozilla's Developer Network and
at worst a complete waste of time (which is my opinion).

Those are the two major JavaScript books that I have read and--in the
case of the latter book, unfortunately--purchased. I own another, but
its quality is so dubious that I will not cite it. Other authors such as
Danny Goodman have attempted to cover JavaScript at length. A
perusal of the c.l.j. archives will evince that heavy scepticism is
advised whilst reading his work.

> I already have 3, but NONE of them, as I discovered to my downfall
> recently, covered for example, hashes, or how they are treated as
> objects. I don't wish to go on my expertise alone, as it's failed
> me - I want some experts to recommend a book which will cover
> everything.

If there is a book that covers *everything* on a specific topic, I
would like to know of it. Of course, that is likely to be impossible.
Because topics--and therefore, technologies--evolve, one
comprehensive effort can quickly become outdated. Donald Knuth has
been writing the *The Art of Computer Programming* series for decades,
and some portions are already considered by some as outdated.

Of the JavaScript books that I have read, zero have covered the DOM
in sufficient detail. That book still needs to be written.
Consequently I advise the following options:

1. Read the previously cited c.l.j. FAQ. It covers a wide variety of
topics, including HTML, CSS, and the DOM API.

2. Read both the ECMA-262 3rd (ES3)[0] and 5th (ES5)[1] edition
specifications. The ES3 specification will equip you with knowledge
that is relevant to older environments that implement it (or in the
case of *M*icro*S*oft *I*nternet *E*xplorer, something similar to it),
whereas the ES5 specification is relevant to modern browsers. I suggest
that the former specification be read before the latter. Both are
available--and are cited--in HTML format.

3. Read material on the DOM API. I recommend starting with a DOM 0
reference[2]. Once a base of knowledge has been established, ascend
the DOM ladder (with each level denoting a "rung"). The DOM Core
specifications are intended to cover multiple document types, whereas
the DOM HTML specifications are intended to cover HTML documents.

4. Research the `window` object. The W3C has provided a draft[3] for
it; and it is also covered in the HTML 5 specification[4].

5. Experiment with this knowledge by testing it in various browsers.
Mozilla[5], Microsoft[6], Opera[7], Apple[8], and Google[9] have all
documented implementation-specific behaviour to some degree.

[0]: http://bclary.com/2004/11/07/
[1]: http://ecma-international.org/ecma-262/5.1/
[2]: http://docs.oracle.com/cd/E19957-01/816-6408-10/
[3]: http://www.w3.org/TR/Window/
[4]: http://www.whatwg.org/specs/web-apps/current-work/
multipage/browsers.html#the-window-object
[5]: https://developer.mozilla.org
[6]: http://msdn.microsoft.com/en-us/library/ms533050%28v=VS.85%29.aspx
[7]: http://dev.opera.com/
[8]: https://developer.apple.com/devcenter/safari/index.action
[9]: http://www.chromium.org/developers

--
`The theologian Meric Casaubon argued--in his 1668 book, *Of Credulity
and Incredulity*--that witches must exist because, after all, everyone
believes in them. Anything that a large number of people believe must
be true.'--Carl Sagan--*The Demon-Haunted World*.

[Matt McDonald]

On 08/10/12 11:38, Matt McDonald wrote:

> [long, unbroken lines of text]

I apologise for allowing Mozilla's *Thunderbird* to play games with
line breaks. I will henceforth write replies in vIM.

[Danny]

hmmm, you never specified what 'GOOD' stood for, if you meant to help you learn js, then I'd say The Bible will do IMHO, on the other hand if you want a reference book, Flanagan's Definitive Guide is one of the more thorough I've found, I have that and others for referencing like Professional JavaScript with Nicholas Zakas.

[Patricia Shanahan]

I'm a JavaScript beginner with a lot of programming experience in other
languages. I'm reading Nicholas Zakas "Professional JavaScript". It
seems very clear, and I like the idea of indicating which browsers
implement which features.

However, I plan to read multiple books and relevant standards, consult
web sites on areas that seem difficult or may vary between browsers, and
do many experiments to confirm I'm understanding what I read.

So far, I don't think I've learned any programming language for which
everything I needed to know was in one book, and I don't expect
JavaScript to be any different.

Patricia

[John G Harris]

On Mon, 8 Oct 2012 at 16:11:47, in comp.lang.javascript, Stefan Weiss
wrote:

<snip>

>(Objects may be implemented as some
>form of hash table or hash map internally, but that's of no consequence
>to users.)

<snip>

This is unlikely, as it happens.

One of the proposals for the abandoned ES4 was for 'for-in' to access
properties in insertion order. Apparently enough web designers relied on
this undocumented behaviour in NS and IE that it was thought worth
standardising.

A hash table implementation would make this behaviour difficult to
implement. Telling annoyed web designers whose pages stop working that
it's their own fault for relying on undocumented behaviour has never
been popular.

John
--
John Harris

[Stefan Weiss]

Alright, now you've made me curious :)

I had an older version of the Rhino source code lying around, and as you
said, the notion that JavaScript objects are internally modeled as
derivatives of HashMaps is too simplistic - by far! From what I can see
at a quick glance, the internal representations of objects are derived
from the ScriptableObject class, which defines its own Slot inner class
to store JS properties. The slots each have "next" and "orderedNext"
properties, but there's so much else going on in there that it would
take me too long to completely understand it (including lookups in the
prototype chain, DontEnum, getters, etc). Ultimately, however, the
actual current values appear to be stored in an ordinary HashMap named
associatedValues.

- stefan

[I Am Here]

Thanks guys, for all the replies. Count on me as a new addition to this group :)

The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself Javascript in 24 hours" and one called "HTML, XHTML, CSS and Javascript" which is absolutely useless. Also, I recently bought "Supercharged Javascript Graphics" where I can't follow the code, which is what brought me to this group.

Yes, it's the referring to object properties as array subscripts that I find confusing, but also as colon separated items inside a {} block. I'll post more on this when my head clears up a little, I've got a slight fever at the moment, and I just can't stay at the computer too long :)

Anyway, a little introduction telling me which country each of you are from would be nice to start with :) Me, I'm Indian.


Bye for the moment.

[Gregor Kofler]

The titles indicate that the content of these books *must* be utter crap.

So far Crockford's "JS The Good Parts" has been the only JS book I found
worth reading.

Gregor

[Patricia Shanahan]

It could be implemented using a combined doubly linked list and hash
table, similar to Java's LinkedHashMap. Append each new entry to the
linked list, use the hash map to find entries, and update the linked
list when an item is removed. The linked list is used to iterate in
order of appearance.

However, JavaScript has a fairly complicated scope structure. Hash maps
for identifier lookup make most sense if there are a lot of identifiers
in one undifferentiated scope. Linked lists are faster and more compact
than hash maps for small numbers of entries.

Patricia

[Gene Wirchenko]

"*must*"?

Jo(e) Author writes the definitive JavaScript book. The
publisher gives it a title you do not like. Hmm.

>So far Crockford's "JS The Good Parts" has been the only JS book I found
>worth reading.

After not trusting books bacause of titles, you trust a book with
"crock" in the author's name? If you are going to be bigoted, please
be consistent about it.

Sincerely,

Gene Wirchenko

[Stefan Weiss]

On 2012-10-09 18:43, Gregor Kofler wrote:
> So far Crockford's "JS The Good Parts" has been the only JS book I found
> worth reading.

It's certainly worth reading, but for the OP: this book does not teach
JavaScript; instead it defines a subset of the language and calls it
"The Good Parts". Some of the "bad" and the "ugly" parts are also
mentioned in passing, but the book is in no way a reference of what's
syntactically possible in JavaScript or ECMAScript. Crockford's JSLint
behaves in much the same way, as it will sometimes stop parsing and
complain about a supposed syntax error, where the syntax is actually
valid ES, but not included in Crockford's idea of good style.

I would recommend the book for advanced readers, not for beginners. When
reading it, I would also recommend keeping in mind what the book
actually is: a longish opinion piece about what the language should have
been, according to one person.

- stefan

[Scott Sauyet]

Gene Wirchenko wrote:
> Gregor Kofler wrote:
>> schrieb I Am Here:

>>> The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself
>>> Javascript in 24 hours" and one called "HTML, XHTML, CSS and
>>> Javascript" which is absolutely useless. Also, I recently bought
>>> "Supercharged Javascript Graphics" where I can't follow the code,
>>> which is what brought me to this group.

>>> [ ... ]

>> The titles indicate that the content of these books *must* be utter crap.
>
>      "*must*"?

No, of course not, but we're all entitled to some minor hyperbole, no?

> Jo(e) Author writes the definitive JavaScript book.  The
> publisher gives it a title you do not like.  Hmm.

There are a lot of demands on my time, and plenty of books that I
might want to read, including, these days, plenty of books on
Javascript. So the initial weeding out is going to be fairly
ruthless. The title and author are going to be the first things I
consider. So, if I hear "Javascript Cookbook", my first thought is
that it's supplying a collection of recipes, means to solve predefined
problems. I have a few O'Reilly Cookbooks; one of them is a decent
book, but none of them is something I would suggest as a way to learn
the basics of a language, or even as a good means of progressing from
basic to intermediate. So in lieu of any further information, that
one immediately sounds like a bad idea for a beginner.

Then we have "Sams Teach Yourself Javascript in 24 Hours". I've only
seen these Sams Teach Yourself X in 24 Hours books; I've never
bothered to read them because I've rarely wanted to buy a book on
something that I thought I could learn in a day. Either the title is
overoptimistic or the subject is too trivial to write a book about.
So I see no reason to pick this book up, unless something else (most
likely a recommendation from someone I trust) says otherwise.

And finally, "HTML, XHTML, CSS and Javascript". This is much more
promising. If I'm looking for a book on Web Technologies, there is
nothing in this title to suggest anything wrong. But if I want to
focus on Javascript, the title is going to make me think that my
material is going to make up only about a quarter of the book.
Perhaps I should look elsewhere for a dedicated book.

So perhaps you shouldn't judge a book by its cover -- or its title --
but if the author and/or publishers have buried the worthwhile content
behind a misleading title, I don't feel too bad about overlooking it
until further evidence is unearthed.

-- Scott

[Gregor Kofler]

Am 2012-10-09 19:06, Gene Wirchenko meinte:

> On Tue, 09 Oct 2012 18:43:47 +0200, Gregor Kofler
> <use...@gregorkofler.com> wrote:
>
>> Am 2012-10-09 15:19, schrieb I Am Here:
>>> Thanks guys, for all the replies. Count on me as a new addition to this group :)
>>>
>>> The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself Javascript in 24 hours" and one called "HTML, XHTML, CSS and Javascript" which is absolutely useless. Also, I recently bought "Supercharged Javascript Graphics" where I can't follow the code, which is what brought me to this group.
>>>
>>> Yes, it's the referring to object properties as array subscripts that I find confusing, but also as colon separated items inside a {} block. I'll post more on this when my head clears up a little, I've got a slight fever at the moment, and I just can't stay at the computer too long :)
>>>
>>> Anyway, a little introduction telling me which country each of you are from would be nice to start with :) Me, I'm Indian.
>>
>> The titles indicate that the content of these books *must* be utter crap.
>
> "*must*"?

Well... yes.

"JavaScript Cookbook" - recipes for problems the author seems worth
writing about.

"Teach Yourself JS in 24 Hours" - makes me wonder, why "I am here" is
here (in this NG).

"HTML, XHTML, CSS and Javascript" - PHP, Apache, MySQL and Python is
missing...

(I miss the "Way of the JavaScript Ninja" or whatever it was called.)

> Jo(e) Author writes the definitive JavaScript book. The
> publisher gives it a title you do not like. Hmm.

Joe Author should be man enough to get the title he or she seems
appropriate.

>> So far Crockford's "JS The Good Parts" has been the only JS book I found
>> worth reading.
>
> After not trusting books bacause of titles, you trust a book with
> "crock" in the author's name? If you are going to be bigoted, please
> be consistent about it.

The title is fitting. I don't care about author's names.


Gregor

[Scott Sauyet]

I Am Here wrote:
> Can someone recommend me a good book which will cover ALL important
> features of Javascript?

No.

As some have suggested (although others have disagreed), David
Flanagan's _JavaScript: The Definitive Guide_ is worth a read. I've
owned four of the six editions over the years (1, 3, 5, & 6) and it's
continuously improved. To my mind, it's by far the best overall
reference to the language available in a single volume. But don't
take it as being as definitive as its title suggests. It has its
warts like all such books.

Douglas Crockford's _JavaScript: The Good Parts_ is absolutely worth
reading. But pay attention to the caveats Stefan voiced. It is
opinionated, and while his opinions are well thought out, they are not
necessarily better than your own. Read it. Learn from it. But take
it with a large grain of salt.

Stoyen Stefanov's _JavaScript Patterns_ shows a number of excellent
techniques for organizing code to achieve various ends. It is not a
beginner book, but once you understand the basics of the language,
it's definitely worth a read, and might help people more accustom to
languages like Java and C++/C# bridge the gap to Javascript.

Nicolas Zakas's _High Performance Javascript_ teaches a great deal
about how to build larger-scale systems that use Javascript. If you
need to build large Javascript systems, this is worth a read. But
this material is already a little dated, and will likely become more
so unless further editions are released. Again, this is not a first
book on Javascript.

I have not been entirely through this one myself, but I hear really
good things about _Eloquent Javascript_, by Marijn Haverbeke. This is
an actual beginner tutorial, with enough in-depth material to bring
the reader up to at least an intermediate level.

The only book I know of on Javascript testing is Christian Johansen's
_Test-Driven JavaScript Development_. This is quite well done and
absolutely worth a read if you are interested in unit testing your
Javascript.

-- Scott

[Gregor Kofler]

Am 2012-10-09 20:09, Stefan Weiss meinte:

Agreed. If I look for reference (or learning) I'd suggest online
ressources. My personal favorite is MDN, which also hosts a nice
introduction:

<https://developer.mozilla.org/en-US/docs/JavaScript/Guide>

Gregor

[Patricia Shanahan]

Scott Sauyet wrote:
...

> Then we have "Sams Teach Yourself Javascript in 24 Hours". I've only
> seen these Sams Teach Yourself X in 24 Hours books; I've never
> bothered to read them because I've rarely wanted to buy a book on
> something that I thought I could learn in a day. Either the title is
> overoptimistic or the subject is too trivial to write a book about.
> So I see no reason to pick this book up, unless something else (most
> likely a recommendation from someone I trust) says otherwise.

I have used one of those books, when I needed to get some basics of Java
down in a hurry.

I actually did it in about 24 hours of working time, over a long
weekend, but I think it might have taken longer for someone without much
practice at learning programming languages.

It would not have worked as the only book for my Java education. I've
read many other books, the Java Language Specification, big chunks of
the API documentation etc.

If you need to rapidly get to being able to program a bit in a language,
and have to do it in a very short time, it may be worth looking at the
appropriate Teach Yourself XXX in 24 Hours, but don't imagine you have
finished learning the language at the end of the book.

I skipped that book for JavaScript because I do have more than 24 hours
to learn it, and wanted to go straight to a more thorough treatment.

Patricia

[Gene Wirchenko]

On Tue, 9 Oct 2012 11:43:20 -0700 (PDT), Scott Sauyet
<scott....@gmail.com> wrote:

>Gene Wirchenko wrote:
>> Gregor Kofler wrote:
>>> schrieb I Am Here:
>
>>>> The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself
>>>> Javascript in 24 hours" and one called "HTML, XHTML, CSS and
>>>> Javascript" which is absolutely useless. Also, I recently bought
>>>> "Supercharged Javascript Graphics" where I can't follow the code,
>>>> which is what brought me to this group.
>>>> [ ... ]
>
>>> The titles indicate that the content of these books *must* be utter crap.
>>
>> � � �"*must*"?
>
>No, of course not, but we're all entitled to some minor hyperbole, no?

When it is advice on the very area, it makes the advice much less
valuable.

>> Jo(e) Author writes the definitive JavaScript book. �The
>> publisher gives it a title you do not like. �Hmm.

[snipped argument that I could write]

>So perhaps you shouldn't judge a book by its cover -- or its title --
>but if the author and/or publishers have buried the worthwhile content
>behind a misleading title, I don't feel too bad about overlooking it
>until further evidence is unearthed.

I quite agree. Let me add "for Dummies" books to the list.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 09 Oct 2012 20:55:20 +0200, Gregor Kofler

<use...@gregorkofler.com> wrote:

>Am 2012-10-09 19:06, Gene Wirchenko meinte:
>> On Tue, 09 Oct 2012 18:43:47 +0200, Gregor Kofler
>> <use...@gregorkofler.com> wrote:
>>
>>> Am 2012-10-09 15:19, schrieb I Am Here:
>>>> Thanks guys, for all the replies. Count on me as a new addition to this group :)
>>>>
>>>> The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself Javascript in 24 hours" and one called "HTML, XHTML, CSS and Javascript" which is absolutely useless. Also, I recently bought "Supercharged Javascript Graphics" where I can't follow the code, which is what brought me to this group.
>>>>
>>>> Yes, it's the referring to object properties as array subscripts that I find confusing, but also as colon separated items inside a {} block. I'll post more on this when my head clears up a little, I've got a slight fever at the moment, and I just can't stay at the computer too long :)
>>>>
>>>> Anyway, a little introduction telling me which country each of you are from would be nice to start with :) Me, I'm Indian.
>>>
>>> The titles indicate that the content of these books *must* be utter crap.
>>
>> "*must*"?
>
>Well... yes.

No. They might well not be suitable, but a mistitled book is
still useful.

>"JavaScript Cookbook" - recipes for problems the author seems worth
>writing about.
>
>"Teach Yourself JS in 24 Hours" - makes me wonder, why "I am here" is
>here (in this NG).
>
>"HTML, XHTML, CSS and Javascript" - PHP, Apache, MySQL and Python is
>missing...

Why no. The title includes browser-side only.

>(I miss the "Way of the JavaScript Ninja" or whatever it was called.)
>
>> Jo(e) Author writes the definitive JavaScript book. The
>> publisher gives it a title you do not like. Hmm.
>
>Joe Author should be man enough to get the title he or she seems
>appropriate.

It has nothing to do with manhood, but with marketing and
contracts.

>>> So far Crockford's "JS The Good Parts" has been the only JS book I found
>>> worth reading.
>>
>> After not trusting books bacause of titles, you trust a book with
>> "crock" in the author's name? If you are going to be bigoted, please
>> be consistent about it.
>
>The title is fitting. I don't care about author's names.

Nor I much. I was poking fun.

Sincerely,

Gene Wirchenko

[Evertjan.]

I Am Here wrote on 09 okt 2012 in comp.lang.javascript:

> Thanks guys, for all the replies. Count on me as a new addition to
> this group :)
>
> The 3 books I have are "Javascript Cookbook", "Sams Teach Yourself
> Javascript in 24 hours" and one called "HTML, XHTML, CSS and
> Javascript" which is absolutely useless. Also, I recently bought
> "Supercharged Javascript Graphics" where I can't follow the code,
> which is what brought me to this group.

Javascrit has many different implementations that run on different
platforms and applications. It seems the total is too difficult for
writers with dollar-signs in their eyes.

> Yes, it's the referring to object properties as array subscripts that
> I find confusing, but also as colon separated items inside a {} block.
> I'll post more on this when my head clears up a little, I've got a
> slight fever at the moment, and I just can't stay at the computer too
> long :)
>
> Anyway, a little introduction telling me which country each of you are
> from would be nice to start with :)

More often than not, we either have the country in the signature, or our
emailadres suggests it.

> Me, I'm Indian.

Can mean two things, [we] Europeans suspect you are from India,
the Americans think you are from an American "first nation".

> Bye for the moment.

Wouldn't it be nice if we had your name, so we recognize your next
posting. A usenet conform signature would be even nicer.

Hopefuly it is only the fever that made you forget.

I wish you a speedy recovery.

[Gene Wirchenko]

On Tue, 09 Oct 2012 21:01:02 +0200, Gregor Kofler
<use...@gregorkofler.com> wrote:

[snip]

>Agreed. If I look for reference (or learning) I'd suggest online
>ressources. My personal favorite is MDN, which also hosts a nice
>introduction:
>
><https://developer.mozilla.org/en-US/docs/JavaScript/Guide>

After a quick look, it looks reasonable. Thank you for posting
this link.

Sincerely,

Gene Wirchenko

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> [An object] could be implemented using a combined doubly linked list and

> hash table, similar to Java's LinkedHashMap. Append each new entry to the
> linked list, use the hash map to find entries, and update the linked
> list when an item is removed. The linked list is used to iterate in
> order of appearance.
>
> However, JavaScript has a fairly complicated scope structure.

First of all, JavaScript is an implementation of ECMAScript. One of many.
And ECMAScript gives its conforming implementations a wide latitude.
Ascribing features of the standard to the implementation of the standard and
vice-versa is the first capital beginner's mistake in this field:

<http://PointedEars.de/es-matrix>

The second one is ascribing features (and failings) of the host environment
API to the implementation or the standard. You will find both often in
books and on Web sites actually not worth reading.

> Hash maps for identifier lookup make most sense if there are a lot of
> identifiers in one undifferentiated scope. Linked lists are faster and
> more compact than hash maps for small numbers of entries.

Second, what has scope to do with the way objects are implemented?

--
When all you know is jQuery, every problem looks $(olvable).

[Thomas 'PointedEars' Lahn]

Matt McDonald wrote:

> On 08/10/12 11:38, Matt McDonald wrote:
> > [long, unbroken lines of text]
>
> I apologise for allowing Mozilla's *Thunderbird* to play games with
> line breaks. I will henceforth write replies in vIM.

I can see nothing wrong with your article. Your perception of your article,
however, is tainted by Thunderbird supporting format=flowed and your using
both; which you can see by pressing Ctrl+U when your article is focused in
the list.


HTH

PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[Daniel Pitts]

Quite a lot when you start talking about prototypes, the concepts are
about the same. You have to search several lists until you find a match.

Though, "small numbers of entries" is an indefinite value. It does
probably depend largely (though not entirely) on the size of the "map"
whether a linked-list or hash-map implementation is faster. However, a
linked hash-map is *probably* fast enough for most JS use-cases, but I
couldn't be certain without tests.

Didn't Google do something fancy with chromes script engine to convert
object properties to real "class fields"?

[Patricia Shanahan]

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>
>> [An object] could be implemented using a combined doubly linked list and
>> hash table, similar to Java's LinkedHashMap. Append each new entry to the
>> linked list, use the hash map to find entries, and update the linked
>> list when an item is removed. The linked list is used to iterate in
>> order of appearance.
>>
>> However, JavaScript has a fairly complicated scope structure.
>
> First of all, JavaScript is an implementation of ECMAScript. One of many.
> And ECMAScript gives its conforming implementations a wide latitude.
> Ascribing features of the standard to the implementation of the standard and
> vice-versa is the first capital beginner's mistake in this field:
>
> <http://PointedEars.de/es-matrix>

While technically correct, this seems perhaps just a shade pedantic.
For example, most of the books that have been mentioned favorably in
this thread include the same beginner mistake in their titles.

>
> The second one is ascribing features (and failings) of the host environment
> API to the implementation or the standard. You will find both often in
> books and on Web sites actually not worth reading.
>
>> Hash maps for identifier lookup make most sense if there are a lot of
>> identifiers in one undifferentiated scope. Linked lists are faster and
>> more compact than hash maps for small numbers of entries.
>
> Second, what has scope to do with the way objects are implemented?
>

I meant scope in the generic sense of anything that affects which sets
of identifier-entity mappings have to be searched to find the meaning of
an identifier reference. That includes the prototype chain for a
reference in an object.

My main language implementation experience is with C and Fortran. C, in
particular, tends to have a very large set of global identifiers. I have
done performance measurement on identifier lookup in a C compiler I was
implementing. For that case, a hash table was a lot faster than a linked
list, and performance tuning the hash table got measurable improvements
in compile time.

Hash tables have a significant overhead in space and time, but O(1)
lookup complexity. Linked lists have very low overhead in both time and
space, but O(n) lookup complexity. The choice of which to use should be
based on the number of entries.

I don't see where a typical browser implementation of what is commonly
called JavaScript is going to get a large enough flat pool of
identifiers to make hashing worth while.

Patricia

[Scott Sauyet]

Gregor Kofler wrote:
> (I miss the "Way of the JavaScript Ninja" or whatever it was called.)

I think _Secrets of the Javascript Ninjas_ is actually about to be
released, believe it or not. I do technical reviews for some Manning
books, and they just asked me for my mailing address for the
complimentary paper copy they send to their technical reviewers. I'm
guessing that means that it will hit the shelves quite soon.

Like other of Resig's work, it is a mix of some very good and some ...
let's say less good ... content, or it was when I did my last review
of it several years ago.

-- Scott

[John G Harris]

On Tue, 9 Oct 2012 at 18:43:47, in comp.lang.javascript, Gregor Kofler
wrote:

<snip>

>So far Crockford's "JS The Good Parts" has been the only JS book I
>found worth reading.

His code for emulating Java-like constructors and inheritance are an
example of horrible software design, and his reason for doing this is
remarkably feeble.

On the other hand, scattered here and there through the book are the
things in ECMAScript that are traps for the unwary. Because of this, I
mark the book as high as 2 out of 10.

John
--
John Harris

[John G Harris]

On Tue, 9 Oct 2012 at 13:12:40, in comp.lang.javascript, Stefan Weiss
wrote:

<snip>

>I had an older version of the Rhino source code lying around, and as you
>said, the notion that JavaScript objects are internally modeled as
>derivatives of HashMaps is too simplistic

...

>Ultimately, however, the
>actual current values appear to be stored in an ordinary HashMap named
>associatedValues.

One big problem with hash tables is that the hashing function must be
unlikely to put most entries in one bucket, so giving lousy performance.
Has anyone ever published rules for choosing property names that
optimise performance ?

John
--
John Harris

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> [An object] could be implemented using a combined doubly linked list and
>>> hash table, similar to Java's LinkedHashMap. Append each new entry to
>>> the linked list, use the hash map to find entries, and update the linked
>>> list when an item is removed. The linked list is used to iterate in
>>> order of appearance.
>>>
>>> However, JavaScript has a fairly complicated scope structure.
>>
>> First of all, JavaScript is an implementation of ECMAScript. One of
>> many. And ECMAScript gives its conforming implementations a wide
>> latitude. Ascribing features of the standard to the implementation of the
>> standard and vice-versa is the first capital beginner's mistake in this
>> field:
>>
>> <http://PointedEars.de/es-matrix>
>
> While technically correct, this seems perhaps just a shade pedantic.

Yes, it only seems to be so. But apparently it takes years of experience to
see that.

> For example, most of the books that have been mentioned favorably in
> this thread include the same beginner mistake in their titles.

So what? I cannot recommend any of those books for that and other reasons
either. That something is in a book does not mean it is correct or any
good. Books need to *sell*.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

[Stefan Weiss]

On 2012-10-10 16:32, John G Harris wrote:
> One big problem with hash tables is that the hashing function must be
> unlikely to put most entries in one bucket, so giving lousy performance.
> Has anyone ever published rules for choosing property names that
> optimise performance ?

I don't know about published, but since some runtimes are open source,
we could just take a look at the hash functions. In the case of Rhino,
the underlying hash method for String objects is
java.lang.String.hashCode(). String values are hashed like this:

public int hashCode() {
int h = hash;
if (h == 0 && count > 0) {
int off = offset;
char val[] = value;
int len = count;

for (int i = 0; i < len; i++) {
h = 31*h + val[off++];
}
hash = h;
}
return h;
}

http://www.docjar.com/html/api/java/lang/String.java.html#1481

So in this case, to avoid collisions you'd want to avoid property names
where the character values of the last characters are exactly 31 apart.
For example, the strings "ab" and "bC" will have the same hash value
(3105). The length of the string does not matter: "XXXXXXXXab" and
"XXXXXXXXbC" still have the same hash (1887221793).

As interesting as that may be, I don't think it has much practical
relevance for JS programming. For one thing, all current major ES
implementations in browsers are written in C++, and so will likely use a
different algorithm (I'm too lazy to dive into the v8 source now to see
which type of container is used there). For another thing, exactly how
the hash functions work is not part of their contract - the algorithm
may change at any time.

And finally, if I had to choose between nicely hashable property names
and easily understandable names, I would choose the latter. The most
common performance problems in browser scripting are DOM- and memory-
related, anyway.

At least in Java, if you want to make sure there are no collisions, use
single-letter variable names, like our Doctor :)


- stefan

[John G Harris]

On Wed, 10 Oct 2012 at 20:13:04, in comp.lang.javascript, Stefan Weiss
wrote:

<snip>

>And finally, if I had to choose between nicely hashable property names
>and easily understandable names, I would choose the latter. The most
>common performance problems in browser scripting are DOM- and memory-
>related, anyway.

<snip>

Yes, but some people write about the effect of spaces used to make a
program readable and about the performance of different ways to access
properties, so I'm surprised they haven't written about this.

John
--
John Harris

[John G Harris]

On Wed, 10 Oct 2012 at 15:58:33, in comp.lang.javascript, Tim Streater
wrote:
>In article <nAf1eOFe...@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD
>>,

>John G Harris <jo...@nospam.demon.co.uk> wrote:
>
>> On Tue, 9 Oct 2012 at 18:43:47, in comp.lang.javascript, Gregor Kofler
>> wrote:
>> <snip>
>> >So far Crockford's "JS The Good Parts" has been the only JS book I
>> >found worth reading.
>> His code for emulating Java-like constructors and inheritance are an
>> example of horrible software design, and his reason for doing this is
>> remarkably feeble.
>

>As are any reasons he might advance for having written the book in the
>first place. As has already been said, it's merely one man's opinion
>about what constitutes good style.

It's worse than just his personal style. He tells lies about the
language as well.

John
--
John Harris

[Scott Sauyet]

John G Harris wrote:
> Tim Streater wrote:
>> John G Harris wrote:

>>> Gregor Kofler wrote:

>>>> So far Crockford's "JS The Good Parts" has been the only JS book I
>>>> found worth reading.

>>>  His code for emulating Java-like constructors and inheritance are an
>>> example of horrible software design, and his reason for doing this is
>>> remarkably feeble.

>> As are any reasons he might advance for having written the book in the
>> first place. As has already been said, it's merely one man's opinion
>> about what constitutes good style.

> It's worse than just his personal style. He tells lies about the
> language as well.

For example?

I've found many places where I disagree with his opinions, but I
haven't noticed anything that look like lies to me. What have you
seen?

-- Scott

[John G Harris]

On Thu, 11 Oct 2012 at 06:52:29, in comp.lang.javascript, Scott Sauyet

See my book review in this news group dated 11 Jul 2009 with message ID
8E0bVrIn...@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD

John
--
John Harris

[Scott Sauyet]

John G Harris wrote:
> Scott Sauyet wrote:
>> John G Harris wrote:

[RE: Crockford's _JavaScript: The Good Parts]

>>> It's worse than just his personal style. He tells lies about the
>>> language as well.
>
>> For example?
>
>> I've found many places where I disagree with his opinions, but I
>> haven't noticed anything that look like lies to me.  What have you
>> seen?
>
> See my book review in this news group dated 11 Jul 2009 with message ID
>   8E0bVrIn...@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD

I did find it archived at

<https://groups.google.com/group/comp.lang.javascript/msg/
e798d5c2bf041b0b>

I really didn't see anything in your list that seemed likely to be
considered a lie. The only comment that you made there that might
possibly be construed as a belief that he was lying was this:


| 3 He says that a property's value cannot be 'undefined'. This is
| untrue. (p20)

Even here, I would have taken it to mean that he was mistaken and not
that he was lying.

Odd.

-- Scott

[Dr J R Stockton]

In comp.lang.javascript message <u9udnWjOFPbPlujNnZ2dnUVZ_sadnZ2d@earthl
ink.com>, Wed, 10 Oct 2012 06:44:50, Patricia Shanahan <pa...@acm.org>
posted:

>Hash tables have a significant overhead in space and time, but O(1)
>lookup complexity. Linked lists have very low overhead in both time and
>space, but O(n) lookup complexity. The choice of which to use should be
>based on the number of entries.

I have an RPN long-integer calculation program (in Pascal/Delphi;
longcalc, on merlyn site) where the instructions are held in a list of
instruction names and pointer-to-routines. Whenever a lookup is
successful, the entry found is promoted by one position. That should
usually speed up access to popular instructions in the current instance
of the program. But I do not recall measuring whether it does.

--
(c) John Stockton, nr London UK. E-addr via Homepage. Turnpike v6.05 MIME.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

[John G Harris]

On Thu, 11 Oct 2012 at 10:39:59, in comp.lang.javascript, Scott Sauyet
wrote:

<snip>

>I did find it archived at
>
> <https://groups.google.com/group/comp.lang.javascript/msg/
>e798d5c2bf041b0b>
>
>I really didn't see anything in your list that seemed likely to be
>considered a lie. The only comment that you made there that might
>possibly be construed as a belief that he was lying was this:
>
>
>| 3 He says that a property's value cannot be 'undefined'. This is
>| untrue. (p20)
>
>Even here, I would have taken it to mean that he was mistaken and not
>that he was lying.
>
>Odd.

1) His is the *only* good coding style.
2) else is *always* followed by { ... } .
3) He says that { ... } is not a statement.
4) He says, or implies by banning it, that there is never a good reason
to call a constructor as an ordinary function.

The first is arrogance. The second contradicts what he puts in the
syntax diagrams.

Teaching the third and fourth to beginners should be made a criminal
offence. To be fair to him (why? -ed) the book does start by saying it's
not for beginners. On the other hand he says the book is for programmers
new to the language, so I'm being too fair.

John
--
John Harris

[Scott Sauyet]

John G Harris wrote:
> Scott Sauyet wrote:

[RE: Crockford's _JavaScript: The Good Parts]

>  <https://groups.google.com/group/comp.lang.javascript/msg/e798d5c2bf041b0b>

>
>> I really didn't see anything in your list that seemed likely to be

>> considered a lie.  [ ... ]

>
> 1) His is the *only* good coding style.
> 2) else is *always* followed by { ... } .
> 3) He says that { ... } is not a statement.
> 4) He says, or implies by banning it, that there is never a good reason
>    to call a constructor as an ordinary function.
>
> The first is arrogance. The second contradicts what he puts in the
> syntax diagrams.
>
> Teaching the third and fourth to beginners should be made a criminal
> offence. To be fair to him (why? -ed) the book does start by saying it's
> not for beginners. On the other hand he says the book is for programmers
> new to the language, so I'm being too fair.

Obviously we have very different notions of what it means to lie.

I disagree with Crockford, but I probably also disagree with you on
some of these points. I don't think you're lying about them.

-- Scott

[Gene Wirchenko]

On Fri, 12 Oct 2012 10:37:06 +0100, John G Harris
<jo...@nospam.demon.co.uk> wrote:

[snip]

>1) His is the *only* good coding style.

This is enough to say no. I have a coding style I prefer. It
may be better than yours, but how would I know unless I know what you
work with/in/on?

Even if it is better, it might only be better in the areas that I
work in. Or either of our styles might work fine.

It is like "best practices". You are not against best practices,
are you? How could you be against best practices? The label is not
the thing.

[snip]

Sincerely,

Gene Wirchenko

[Scott Sauyet]

Gene Wirchenko wrote:
> John G Harris wrote:
[RE: Crockford's _JavaScript: The Good Parts]

>> 1) His is the *only* good coding style.
>
> This is enough to say no.  I have a coding style I prefer.  It
> may be better than yours, but how would I know unless I know what you
> work with/in/on?

Just remember that the above is not a quote, only John's
interpretation of Crockford's book.

Crockford absolutely is opinionated about style, and JSLint captures
his opinions in a very detailed manner. This book is very opinionated
as well, but probably less so about style than about more fundamental
issues.

-- Scott

[Patricia Shanahan]

John G Harris wrote:
> On Thu, 11 Oct 2012 at 10:39:59, in comp.lang.javascript, Scott Sauyet
> wrote:
>
> <snip>
>> I did find it archived at
>>
>> <https://groups.google.com/group/comp.lang.javascript/msg/
>> e798d5c2bf041b0b>
>>
>> I really didn't see anything in your list that seemed likely to be
>> considered a lie. The only comment that you made there that might
>> possibly be construed as a belief that he was lying was this:
>>
>>
>> | 3 He says that a property's value cannot be 'undefined'. This is
>> | untrue. (p20)
>>
>> Even here, I would have taken it to mean that he was mistaken and not
>> that he was lying.
>>
>> Odd.
>
> 1) His is the *only* good coding style.

I've met a lot of people who, completely honestly and sincerely, believe
their preferred style is the only good coding style in some language.
Perhaps he is one of those people, and is expressing what he believes.

> 2) else is *always* followed by { ... } .
> 3) He says that { ... } is not a statement.
> 4) He says, or implies by banning it, that there is never a good reason
> to call a constructor as an ordinary function.
>

Depending on the context and exactly what he wrote, he may be at least
half right about #3.

According to the grammar in
http://www.ecma-international.org/ecma-262/5.1/, Statement can be
expanded to Block, so some blocks are statements. On the other hand,
there are contexts which require Block rather than Statement, for
example in a TryStatement. A block that appears where a statement is not
permitted cannot be a statement.

Following an else is not one of those contexts, so #2 is wrong.

Patricia

[Gene Wirchenko]

I am opinionated, too, but I do not cram it down people's
throats. I tried JSLint, saw that it was catering to prejudices
rather than actual language requirements, and dropped it.

Sincerely,

Gene Wirchenko

[John G Harris]

On Fri, 12 Oct 2012 at 20:32:57, in comp.lang.javascript, Patricia
Shanahan wrote:

<snip>

>According to the grammar in
>http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>expanded to Block, so some blocks are statements. On the other hand,
>there are contexts which require Block rather than Statement, for
>example in a TryStatement. A block that appears where a statement is not
>permitted cannot be a statement.

<snip>

I don't agree with your reasoning there. The standard says 'try' must be
followed by a block statement. If it said that 'try' must be followed by
an if statement that wouldn't stop the if production being a particular
kind of statement. It's merely unusual for there to be any kind of
restriction on what kind of statement can be used in a particular
context.

Also, where you say "so some blocks are statements" you've got it the
wrong way round : so some statements are blocks.

John
--
John Harris

[John G Harris]

On Fri, 12 Oct 2012 at 07:11:56, in comp.lang.javascript, Scott Sauyet
wrote:

<snip>

>Obviously we have very different notions of what it means to lie.

<snip>

I mean telling an untruth that misleads the innocent to their detriment,
and not through the author's carelessness or ignorance.

John
--
John Harris

[Patricia Shanahan]

John G Harris wrote:
> On Fri, 12 Oct 2012 at 20:32:57, in comp.lang.javascript, Patricia
> Shanahan wrote:
>
> <snip>
>> According to the grammar in
>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>> expanded to Block, so some blocks are statements. On the other hand,
>> there are contexts which require Block rather than Statement, for
>> example in a TryStatement. A block that appears where a statement is not
>> permitted cannot be a statement.
> <snip>
>
> I don't agree with your reasoning there. The standard says 'try' must be
> followed by a block statement. If it said that 'try' must be followed by

Could you give me a reference for where you are getting the phrase
"block statement"?

I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
recently downloaded copy of
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
and without finding the phrase. Maybe there is some other document I
should be consulting. If so, please give me a pointer.

> an if statement that wouldn't stop the if production being a particular
> kind of statement. It's merely unusual for there to be any kind of
> restriction on what kind of statement can be used in a particular
> context.
>
> Also, where you say "so some blocks are statements" you've got it the
> wrong way round : so some statements are blocks.

"some statements are blocks" is true, but I did not think it was in any
way in dispute. It contradicts neither "some blocks are statements" nor
"some blocks are not statements".

Patricia

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> John G Harris wrote:

>> Patricia Shanahan wrote:
>> <snip>
>>> According to the grammar in
>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>> expanded to Block, so some blocks are statements. On the other hand,
>>> there are contexts which require Block rather than Statement, for
>>> example in a TryStatement. A block that appears where a statement is not
>>> permitted cannot be a statement.
>> <snip>
>>
>> I don't agree with your reasoning there. The standard says 'try' must be
>> followed by a block statement. If it said that 'try' must be followed by
>
> Could you give me a reference for where you are getting the phrase
> "block statement"?
>
> I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
> recently downloaded copy of
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
> and without finding the phrase. Maybe there is some other document I
> should be consulting. If so, please give me a pointer.

Section "12.1 Block" of the ECMAScript Language Specification, 5.1 Edition
(and all previous Editions; section numbering may differ) is a subsection of
section "12 Statements". That, the productions for the /Statement/ goal
symbol defined in the latter section –

| Statement :
| Block
| VariableStatement
| EmptyStatement
| ExpressionStatement
| IfStatement
| IterationStatement
| ContinueStatement
| BreakStatement
| ReturnStatement
| WithStatement
| LabelledStatement
| SwitchStatement
| ThrowStatement
| TryStatement
| DebuggerStatement

(previous Editions contain the productions starting from LabelledStatement
to a varying degree) –, and that an ECMAScript program is produced from

| 14 Program
|
| Syntax
|
| Program :
| SourceElements_opt
|
| SourceElements :
| SourceElement
| SourceElements SourceElement
|
| SourceElement :
| Statement
| FunctionDeclaration

specify that what can be produced from the Block goal symbol is considered a
statement, or, IOW, that there is a Block statement. This may be
colloquially written "block statement".

The syntax for "12.14 The try Statement" (which *also* is a subsection of
section 12) is:

| TryStatement :
| try Block Catch
| try Block Finally
| try Block Catch Finally
|
| Catch :
| catch ( Identifier ) Block
|
| Finally :
| finally Block

This means that the `try' keyword must be followed by a statement,
specifically a Block statement.

That there is a Block statement and a LabelledStatement in ECMAScript is one
reason why

return
{
foo: "bar"
};

produces unexpected results as it is equivalent to

return;

{
foo: "bar";
};

where the `undefined' value is returned and `foo' is considered a label for
the "bar" ExpressionStatement. Which has been correctly observed by
Crockford, among others.

[His conclusion from that, that Allman style is inappropriate on the whole
in ECMAScript implementations is premature and fallacious, though. For it
is exactly the ambiguity between Block statements and Object initializers,
and Function declarations and Function expressions that makes it a good idea
to format them differently:

if (foo)
{
bar();
}

but

return {
foo: "bar"
};

and

function foo (bar)
{
baz();
}

but

var foo = function (bar) {
baz();
};

and, by extension,

var foo = (function (baz) {
return function bar (foobar) {
return foobar(bar, baz);
};
}(42));

]


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Patricia Shanahan]

I find it interesting that the symbol is "Block", not "BlockStatement".
Things that can only be used as a Statement, such as IfStatement, get
the word "Statement" in their symbols.

> specify that what can be produced from the Block goal symbol is considered a
> statement, or, IOW, that there is a Block statement. This may be
> colloquially written "block statement".

You seem to be confused about my position. I am not saying that no Block
can be a Statement, just that a Block can be used in situations in which
a Statement would not be accepted, and so is not always a Statement.

I have no trouble with colloquially calling those blocks that are
statements "block statements", but do not think colloquial usage is a
good way of analyzing language specifications.

Patricia

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> John G Harris wrote:
>>>> Patricia Shanahan wrote:
>>>> <snip>
>>>>> According to the grammar in
>>>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>>>> expanded to Block, so some blocks are statements. On the other hand,
>>>>> there are contexts which require Block rather than Statement, for
>>>>> example in a TryStatement. A block that appears where a statement is
>>>>> not permitted cannot be a statement.
>>>> <snip>
>>>>
>>>> I don't agree with your reasoning there. The standard says 'try' must
>>>> be followed by a block statement. If it said that 'try' must be
>>>> followed by

(sic!)

BTW, interrupting others in the midst of a sentence is not good quoting
style either.

>>> Could you give me a reference for where you are getting the phrase
>>> "block statement"?
>>>
>>> I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
>>> recently downloaded copy of
>>> http://www.ecma-international.org/publications/files/ECMA

>>> ST/Ecma-262.pdf, and without finding the phrase. Maybe there is some
>>> other document I should be consulting. If so, please give me a pointer.
>>
>> Section "12.1 Block" of the ECMAScript Language Specification, 5.1
>> Edition (and all previous Editions; section numbering may differ) is a
>> subsection of section "12 Statements". That, the productions for the
>> /Statement/ goal symbol defined in the latter section –
>>
>> | Statement :
>> | Block
>> | VariableStatement
>> | EmptyStatement
>> | ExpressionStatement
>> | IfStatement
>> | IterationStatement
>> | ContinueStatement
>> | BreakStatement
>> | ReturnStatement
>> | WithStatement
>> | LabelledStatement
>> | SwitchStatement
>> | ThrowStatement
>> | TryStatement
>> | DebuggerStatement
>
> I find it interesting that the symbol is "Block", not "BlockStatement".

The goal symbol right-hand side is irrelevant, as the Specification is
structured in sections so that it is clear what is a statement and what is
not. And the goal symbol left-hand side emphasizes that.

> Things that can only be used as a Statement, such as IfStatement, get
> the word "Statement" in their symbols.

Nonsense.

>> specify that what can be produced from the Block goal symbol is
>> considered a
>> statement, or, IOW, that there is a Block statement. This may be
>> colloquially written "block statement".
>
> You seem to be confused about my position. I am not saying that no Block
> can be a Statement, just that a Block can be used in situations in which
> a Statement would not be accepted, and so is not always a Statement.

Ex falso quodlibet. A Block (statement) *cannot* be used in situations in
which a Statement would not be accepted. For example, the braces in

function x (y)
{

}

are _not_ produced by /Block/, they are produced as part of

| FunctionDeclaration :
| function Identifier ( FormalParameterListopt ) { FunctionBody }

The braces in

var foo = {
bar: 42
};

are _not_ produced by /Block/ either, they are produced as part of

| ObjectLiteral :
| { }
| { PropertyNameAndValueList }
| { PropertyNameAndValueList , }

(formerly, /ObjectInitialiser/, and a trailing comma was a syntax error).


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> | ObjectLiteral :
> | { }
> | { PropertyNameAndValueList }
> | { PropertyNameAndValueList , }
>

> (formerly, /ObjectInitialiser/, […]).

I have confused that. It was /ObjectLiteral/ in Edition 3 already, and the
prose always used "Object Initialiser" for the section name regardless.

[Patricia Shanahan]

Thomas 'PointedEars' Lahn wrote:
...

> The goal symbol right-hand side is irrelevant, as the Specification is
> structured in sections so that it is clear what is a statement and what is
> not. And the goal symbol left-hand side emphasizes that.

...

I don't think you really mean to argue that being defined in Section 12
makes it clear that a symbol is a Statement, rather than just something
so closely related to statements that it makes sense to put it in the
same section.

See, for example, the Section 12 production

Initialiser :
= AssignmentExpression

Patricia

[Patricia Shanahan]

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:

...

>> You seem to be confused about my position. I am not saying that no Block
>> can be a Statement, just that a Block can be used in situations in which
>> a Statement would not be accepted, and so is not always a Statement.
>
> Ex falso quodlibet. A Block (statement) *cannot* be used in situations in
> which a Statement would not be accepted. For example, the braces in
>
> function x (y)
> {
>
> }
>
> are _not_ produced by /Block/, they are produced as part of
>
> | FunctionDeclaration :
> | function Identifier ( FormalParameterListopt ) { FunctionBody }
>
> The braces in
>
> var foo = {
> bar: 42
> };
>
> are _not_ produced by /Block/ either, they are produced as part of
>
> | ObjectLiteral :
> | { }
> | { PropertyNameAndValueList }
> | { PropertyNameAndValueList , }
>
> (formerly, /ObjectInitialiser/, and a trailing comma was a syntax error).

Have you considered the TryStatement productions?

Patricia

[Thomas 'PointedEars' Lahn]

I have, and that is indeed a case where any other statement but a Block
statement is not allowed. However, that does not prove your argument,
only its premise.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:

>> The goal symbol right-hand side is irrelevant, as the Specification is
>> structured in sections so that it is clear what is a statement and what
>> is not. And the goal symbol left-hand side emphasizes that.
>

> I don't think you really mean to argue that being defined in Section 12
> makes it clear that a symbol is a Statement, rather than just something
> so closely related to statements that it makes sense to put it in the
> same section.

Of course I do mean that. It is not logical to think otherwise.

> See, for example, the Section 12 production
>
> Initialiser :
> = AssignmentExpression

Quoting the Specification out of context does not help your case. The
Initialiser goal symbol is on the right-hand side of the
/VariableDeclaration/ production in section "12.2 Variable Statement". A
/VariableDeclaration/ can only be produced as part of a /VariableStatement/,
through /VariableDeclarationList/, which can only be produced by
/Statement/.

Very obviously all possible outcomes of the /Statement/ production produce a
statement each in these programming languages.


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> (404-comp.)

[Patricia Shanahan]

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:

...

>> Have you considered the TryStatement productions?
>
> I have, and that is indeed a case where any other statement but a Block
> statement is not allowed. However, that does not prove your argument,
> only its premise.

In that case, we may have to just agree to differ. You seem to have a
very deeply built-in assumption that a Block must be a Statement, to the
extent that even when discussing the standard you talk about "a Block
statement", a phrase that does not appear in it, rather than terms such
as "a Block" or "a Block of code", that do appear in the standard.

However, I am very curious about why you wrote so much that seemed to be
refuting the idea that any sequence of statements enclosed in braces
must be a Block. I never claimed that, and it has nothing to do with my
actual claim, which was about Block, not about all brace-enclosed
statement sequences.

Patricia

[John G Harris]

On Sat, 13 Oct 2012 at 19:45:17, in comp.lang.javascript, Patricia

Shanahan wrote:
>John G Harris wrote:
>> On Fri, 12 Oct 2012 at 20:32:57, in comp.lang.javascript, Patricia
>> Shanahan wrote:
>> <snip>
>>> According to the grammar in
>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>> expanded to Block, so some blocks are statements. On the other hand,
>>> there are contexts which require Block rather than Statement, for
>>> example in a TryStatement. A block that appears where a statement is not
>>> permitted cannot be a statement.
>> <snip>
>> I don't agree with your reasoning there. The standard says 'try'
>>must be
>> followed by a block statement. If it said that 'try' must be followed by
>
>Could you give me a reference for where you are getting the phrase
>"block statement"?

<snip>

"block statement" comes from the same verbal contortion that converts
"IfStatement statement" into "if statement". It's not defined, but most
readers will understand what is meant.

Would it help if the name "Block" were replaced by "CompoundStatement",
as in other similar languages. It wouldn't change the syntax nor would
it change the semantics; you'd still have the same language.

(Aside: We don't know why the inventor used "Block". Perhaps it was a
case of "Block" can't be confused with a keyword, unlike "if", and he
was fed up with typing long names.)

Your point about the try statement doesn't follow the usual advice to
Keep It Simple. The Block components in a try statement do exactly the
same job as elsewhere, so why think of them differently, especially as
the standard doesn't even hint at any difference.

John
--
John Harris

[Thomas 'PointedEars' Lahn]

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> Have you considered the TryStatement productions?
>>
>> I have, and that is indeed a case where any other statement but a Block
>> statement is not allowed. However, that does not prove your argument,
>> only its premise.
>
> In that case, we may have to just agree to differ. You seem to have a
> very deeply built-in assumption that a Block must be a Statement, to the
> extent that even when discussing the standard you talk about "a Block
> statement", a phrase that does not appear in it, rather than terms such
> as "a Block" or "a Block of code", that do appear in the standard.

For crying out loud. When something is specified in a subsection of the
main section titled "Statements", and any other subsection of that section
specifies a different statement; when it is directly produced by the
/Statement/ goal symbol as all other direct results of that production that
are defined in the same main section, then it is not very far-fetched to
assume that this something is meant to be a statement as well. Indeed, it
is not logical to assume that the opposite is the case.

But, as they say, the proof is in the pudding. If what is produced by the
/Block/ production would not be a statement, then

{ 42 }

would not be a syntactically valid ECMAScript /Program/, because it cannot
be produced by anything other than the production chain

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /Block/
→ { /StatementList/ }
→ { /Statement/ }
→ { /ExpressionStatement/ }
→ …
→ { 42 }

You will observe, however, that this code compiles in all conforming
implementations without syntax error, and that the result of that /Program/
is 42, because the result of the /Block/ statement is 42, because the result
of the /ExpressionStatement/ 42 is, necessarily, 42. Which is what the
production rules specify.

QED.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

[Gene Wirchenko]

On Sun, 14 Oct 2012 13:40:57 +0100, John G Harris
<jo...@nospam.demon.co.uk> wrote:

[snip]

>"block statement" comes from the same verbal contortion that converts
>"IfStatement statement" into "if statement". It's not defined, but most
>readers will understand what is meant.

It is hardly a contortion. I have used "if statement" since my
first programming which is way before JavaScript existed. Many of us
know more than one programming language.

[snip]

Sincerely,

Gene Wirchenko

[John G Harris]

On Sun, 14 Oct 2012 at 19:03:13, in comp.lang.javascript, Gene Wirchenko
wrote:

>On Sun, 14 Oct 2012 13:40:57 +0100, John G Harris
><jo...@nospam.demon.co.uk> wrote:
>
>[snip]
>
>>"block statement" comes from the same verbal contortion that converts
>>"IfStatement statement" into "if statement". It's not defined, but most
>>readers will understand what is meant.
>
> It is hardly a contortion.

I wasn't saying it's wrong. If I'd called it a verbal elision would you
have understood me ?

>I have used "if statement" since my
>first programming which is way before JavaScript existed. Many of us
>know more than one programming language.

So do I, starting with Deuce Alphacode.

John
--
John Harris

[I Am Here]

Hey,
This thread seems to have gone off-topic quite a bit, but just to answer somebody's question up there, I'm FROM India, and I prefer not to use my real name because things can get quite personal on newsgroups, I might end up making friends and chatting with them, and I wouldn't want, say my BOSS to be able to read them!

Anyway, as I have more questions, I'll post them, but I'm also not giving up on the other place I go to (a web board), where I can get to what *I* posted by clicking on "My Posts", and see what replies have come in quickly.

Bye for now :)