Live data from Hacker News

The Future of JavaScript

blog.chromium.org

11–20 of 115 posts

Re: The Future of JavaScript

#13
post #8

Anyone know where can I request a OrderedMap? That committee Wiki seems hardened against intruders. Would be really unfortunate to have to wait for a native OrderedMap/SortedMap/TreeMap until ES7.

Bring it up on es-discuss https://mail.mozilla.org/listinfo/es-discuss

But please, search the archives first and be aware of what discussions have already taken place on this subject. =]

Re: The Future of JavaScript

#14

    > (Caveat: Iteration over collections is not yet specified)
Is this a joke? Is not iterating over dictionaries and arrays javascript's most glaring weakness?

How hard would it be to agree on something like foreach, that, you know, actually works the way you think it should work.

Re: The Future of JavaScript

#15
Would there be any possibility for the addition of native Long numbers to JavaScript, or is this, due to some nature of the language, something that can't, or shouldn't, be included?

Re: The Future of JavaScript

#16
post #14

> (Caveat: Iteration over collections is not yet specified) Is this a joke? Is not iterating over dictionaries and arrays javascript's most glaring weakness? How hard would it be to agree on something like foreach, that, you know, actually works the way you think it should work.

My guess would be bikeshedding.

Re: The Future of JavaScript

#17
post #14

> (Caveat: Iteration over collections is not yet specified) Is this a joke? Is not iterating over dictionaries and arrays javascript's most glaring weakness? How hard would it be to agree on something like foreach, that, you know, actually works the way you think it should work.

Remember that the spec won't come out for a while, after a pile of additional development. Also remember that we have to live with it for a long time, so taking the time to get it right seems preferable.

Re: The Future of JavaScript

#19
post #9

Earlier quoted context omitted.

It's only an abuse because JavaScript has no distinction between the notion of an object's "meta" properties, and its dictionary-like keys and values. So you'll get along just fine, until someone tries to write this: var dict = {}; dict["hasOwnProperty"] = true; dict["toString"] = "Bob"; dict["valueOf"] = 7; ... then you're in for a rough time.

var map = Object.create(null); ..will not have any of those properties. Works only in v8 though, AFAIK.

I just tested and it looks like it works in SquirrelFish/Nitro and SpiderMonkey as well. Cool trick — I didn't know about that.

But I don't think it quite solves the problem jashkenas is talking about, which is that JavaScript automatically calls certain properties of your object behind the scenes in many situations, so you aren't completely free to use any key you want. You might be able to use a no-proto object like this as the internal datastore for a map, but by itself an object with arbitrarily assigned keys would cause a lot of problems unless you were very careful with it.

Re: The Future of JavaScript

#20
post #15

Would there be any possibility for the addition of native Long numbers to JavaScript, or is this, due to some nature of the language, something that can't, or shouldn't, be included?

You could add a 64-bit int type, sure, but since implementations use pointer-sized data that has to represent other types as well, making it as efficient as a long long in C isn't as easy. Seems unlikely to muster enough priority. (I haven't been following their work, though.)
Post reply on HN