Non-extensibility of Typed Arrays

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

--Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130904/2fffdc39/attachment.html>


More information about the es-discuss mailing list