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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
