On Mon, Oct 28, 2013 at 4:43 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> If there is a better proposal for the "return an array that can be read but
> not written but I can still write to it" use case, I'm all ears.

My suggestion has been:

Return a frozen (and thus immutable) Array.
When you need to change the contents of the array, create a new frozen
Array which contains the new Array contents.

In the case of gamepads, the second rule would kick in when a gamepad
was connected or disconnected.

The "i don't want others to change the array, but I want to be able to
do so myself" is basically a "live array", which a lot of people has
expressed dislike of. So maybe it's something we should avoid.

My proposal above has two nice properties:

x.arrayProp === x.arrayProp returns true.
x.arrayProp behaves entirely like a normal array (including
Array.isArray and Array.concat), as long as you don't try to mutate
it.

/ Jonas

On Mon, Oct 28, 2013 at 4:43 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> If there is a better proposal for the "return an array that can be read but
> not written but I can still write to it" use case, I'm all ears.

My suggestion has been:

Return a frozen (and thus immutable) Array.
When you need to change the contents of the array, create a new frozen
Array which contains the new Array contents.

In the case of gamepads, the second rule would kick in when a gamepad
was connected or disconnected.

The "i don't want others to change the array, but I want to be able to
do so myself" is basically a "live array", which a lot of people has
expressed dislike of. So maybe it's something we should avoid.

My proposal above has two nice properties:

- `x.arrayProp === x.arrayProp` returns `true`.
- `x.arrayProp` behaves entirely like a normal array (including `Array.isArray` and `Array.concat`), as long as you don't try to mutate it.