On Oct 28, 2013, at 5:25 PM, Domenic Denicola wrote:
> 
> I think the issue is that these things are properties, either because of web legacy (as in some specifications) or because the spec writers conceptualize them as such and are reluctant to change them (for the newer specifications). And returning a fresh array from the getter each time is unpleasant. If they could be changed to methods, returning a new object each time makes a lot of sense.
> 
> That said I feel like this is a common enough need that it might be worth the DOM speccing a read-only proxy-onto-an-array view type that they could reuse. As Boris says it would probably be very similar to what ArrayClass does, so maybe ArrayClass is OK as-is, but I feel like fleshing it out in terms of real ES proxies would make it feel less hackish, perhaps?
> 
> (Such a type would be generally useful for not just DOM specs, IMO. Maybe I should work on a library prototyping this and if it's awesome and everyone loves it and uses it, someone can spec it officially.)
> 

So what's so onerous about returning a fresh array from the getter each time it was called.  If it was implemented in Es6, it would just be:
    return Array.from(internal_compy);

Proxies aren't cheap. Unless these arrays tend to be quite large, I wouldn't be surprised if the overhead of using a Proxy for this useless ended up being higher than the cost of making fresh arrays. 

Allen

So what's so onerous about returning a fresh array from the getter each time it was called.  If it was implemented in Es6, it would just be:

```js
return Array.from(internal_compy);
```

Proxies aren't cheap. Unless these arrays tend to be quite large, I wouldn't be surprised if the overhead of using a Proxy for this useless ended up being higher than the cost of making fresh arrays.