[Bug 29004] FrozenArray only provides shallow immutability

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29004

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian@hixie.ch

--- Comment #6 from Travis Leithead [MSFT] <travil@microsoft.com> ---
To me, the "frozen" aspect still seems like a completely unnecessary
protection. The platform has hitherto only offered very few places where we
choose to lock-out modification (e.g., [Unforgeable]). For everything else, if
any one author script decides to ```delete
Document.prototype.getElementById;``` it affects all author script. The reason
this isn't a massive problem today is because author scripts are generally
benevolent and don't accidentally make these changes.

I can see the argument that existing array-like interfaces don't, in fact,
allow mutation today. Take for example, the plugins collection:

```[].push.call(navigator.plugins, { travis: "test"})```
```[].pop.call(navigator.plugins)```

both of which throw an exception today. These would be the kind of mutations
that one author script could do that would damage/inhibit other author script
from having a good experience. (Similar to my delete example above.)

However, the following are OK, and do not throw:

```navigator.plugins["100"] = { travis: "test" };```
```navigator.plugins.test = "value";```

which seem valuable for scenarios that want to supplement the array objects or
provide additional behaviors.

So, FrozenArray keeps the immutability constraint as currently available in the
first set of examples, but further restricts the author's options given what is
possible today as in the second examples.

My argument is that we should be not be swinging toward more restrictive,
rather we should be swinging toward less restrictive and more flexible. E.g.,
allowing the plugins array to be supplemented by a couple new entries could be
very useful for a compatibility shim, and in that case you *do* want the change
to effect all author script.

Furthermore, if the issue is a desire to convert existing array-like things
into FrozenArray (like the plugins collection above), it's very
back-compat-friendly to go from more restrictive to less restrictive because no
existing [successful] author code will already be mutating those arrays.
However, there is a chance that author code may already be supplementing
existing array-like things in the platform, and a FrozenArray conversion would
cause that code to start throwing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 31 July 2015 19:14:37 UTC