Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16466 > unrolled thread

What's a good Javascript book?

Back to article view | Back to comp.lang.javascript

Contents

  What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-08 06:35 -0700
    Re: What's a good Javascript book? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-08 13:52 +0000
      Re: What's a good Javascript book? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-08 17:03 +0300
        Re: What's a good Javascript book? Tim Streater <timstreater@greenbee.net> - 2012-10-08 15:22 +0100
          Re: What's a good Javascript book? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-10-08 08:56 -0600
    Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-08 16:11 +0200
      Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-09 10:43 +0100
        Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-09 13:12 +0200
          Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-10 15:32 +0100
            Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-10 20:13 +0200
              Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 14:28 +0100
        Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-09 17:56 +0100
          Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 00:32 +0200
            Re: What's a good Javascript book? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-10-09 16:37 -0700
            Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-10 06:44 +0100
              Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 20:09 +0200
              Re: What's a good Javascript book? Dr J R Stockton <reply1241@merlyn.demon.co.uk.invalid> - 2012-10-11 19:43 +0100
    Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-08 16:21 +0200
    Re: What's a good Javascript book? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-10-08 07:56 -0700
    Re: What's a good [JavaScript] book? Matt McDonald <matt@fortybelow.ca> - 2012-10-08 11:38 -0400
      Re: What's a good [JavaScript] book? Matt McDonald <matt@fortybelow.ca> - 2012-10-08 11:42 -0400
        Re: What's a good [JavaScript] book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 00:41 +0200
    Re: What's a good Javascript book? Danny <dann90038@gmail.com> - 2012-10-08 11:57 -0700
      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-08 20:39 +0100
    Re: What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-09 06:19 -0700
      Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 18:43 +0200
        Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 10:06 -0700
          Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-09 11:43 -0700
            Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-09 20:07 +0100
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:40 -0700
          Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 20:55 +0200
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:45 -0700
            Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-10 04:31 -0700
        Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-09 20:09 +0200
          Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 21:01 +0200
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:50 -0700
        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-10 15:26 +0100
          Re: What's a good Javascript book? Tim Streater <timstreater@greenbee.net> - 2012-10-10 15:58 +0100
            Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 14:39 +0100
              Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-11 06:52 -0700
                Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 17:13 +0100
                  Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-11 10:39 -0700
                    Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-12 10:37 +0100
                      Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-12 07:11 -0700
                        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-13 10:53 +0100
                      Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-12 09:49 -0700
                        Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-12 10:22 -0700
                          Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-12 13:17 -0700
                      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-12 20:32 +0100
                        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-13 10:50 +0100
                          Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 19:45 +0100
                            Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 21:55 +0200
                              Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 21:52 +0100
                                Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 23:49 +0200
                                  Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 23:57 +0200
                                  Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 23:34 +0100
                                    Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-14 02:09 +0200
                                  Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-14 00:00 +0100
                                    Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-14 01:58 +0200
                                      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-14 07:17 +0100
                                        Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-15 01:17 +0200
                            Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-14 13:40 +0100
                              Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-14 19:03 -0700
                                Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-15 10:42 +0100
      Re: What's a good Javascript book? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-09 22:49 +0200
    Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-09 12:00 -0700
    Re: What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-16 06:57 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#16466 — What's a good Javascript book?

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.

[toc] | [next] | [standalone]

#16467

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>

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

[toc] | [prev] | [next] | [standalone]

#16468

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/

[toc] | [prev] | [next] | [standalone]

#16471

In article <k4umg5$lkj$1@dont-email.me>,
 "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:

> 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.

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.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#16472

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 :)  )

[toc] | [prev] | [next] | [standalone]

#16469

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

[toc] | [prev] | [next] | [standalone]

#16496

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

[toc] | [prev] | [next] | [standalone]

#16499

On 2012-10-09 11:43, John G Harris wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#16533

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

[toc] | [prev] | [next] | [standalone]

#16541

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

[toc] | [prev] | [next] | [standalone]

#16553

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

[toc] | [prev] | [next] | [standalone]

#16503

John G Harris wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#16521

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).

[toc] | [prev] | [next] | [standalone]

#16524

On 10/9/12 3:32 PM, 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>
>
> 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?
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"?

[toc] | [prev] | [next] | [standalone]

#16525

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

[toc] | [prev] | [next] | [standalone]

#16540

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:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#16565

In comp.lang.javascript message <u9udnWjOFPbPlujNnZ2dnUVZ_sadnZ2d@earthl
ink.com>, Wed, 10 Oct 2012 06:44:50, Patricia Shanahan <pats@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.

[toc] | [prev] | [next] | [standalone]

#16470

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.

[toc] | [prev] | [next] | [standalone]

#16473

On Monday, October 8, 2012 8:35:38 AM UTC-5, I Am Here wrote:
> 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.

I have high hopes for this:

http://effectivejs.com/

[toc] | [prev] | [next] | [standalone]

#16475 — Re: What's a good [JavaScript] book?

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*.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web