Non-extensibility of Typed Arrays
oliver at apple.com
Wed Sep 4 16:29:30 PDT 2013
On Sep 4, 2013, at 4:15 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> On Sep 4, 2013, at 3:09 PM, Brendan Eich <brendan at mozilla.com> wrote:
<snip solo much text :D >
>> But with ES5 Object.preventExtensions, etc., the horse is out of the barn.
> It's there and we have to support it, and the fact that you can do preventExtensions() to an object is a good thing. That doesn't mean it should become the cornerstone for every new feature. If a user wants to preventExtensions() on their object, then that's totally cool - and I'm not arguing that it isn't.
> The argument I'm making is a different one: should an object be non-expandable by default?
Actually, here's a very good example: Why do Maps and Sets allow expandos?
* They are logically buckets so an expando properties seem unnecessary
* We have seen in the past that people get really confused about property access -- see the enumerable "associative array" articles that do "new Array()" to get there magical associative array. For (probably) common cases of string and numeric properties:
- someMap["foo"]="bar" and someMap["foo"]; vs.
- someMap.set("foo", "bar") and someMap.get("foo")
are sufficiently close to "the same" that developers _will_ do this, and think that they're using a Map.
So should Map be inextensible by default? The argument against supporting expandos on a typed array seems even stronger for these collection types.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss