On Sep 4, 2013, at 4:15 PM, Filip Pizlo <[email protected]> wrote:
>
> On Sep 4, 2013, at 3:09 PM, Brendan Eich <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
