The post links to an outdated Proxy spec. Here's the right link: http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxie...
The Future of JavaScript
11–20 of 115 posts
Re: The Future of JavaScript
#12Ouch. I guess the end of 2013 is sooner than never.
Re: The Future of JavaScript
#13Anyone 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.
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
#15Re: The Future of JavaScript
#16> (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
#17> (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
#18Would 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
#19Earlier 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.
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
#20Would 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?