- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Tue, 29 Oct 2013 00:25:57 +0000
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>, Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
From: es-discuss [mailto:es-discuss-bounces@mozilla.org] On Behalf Of Allen > I don't think there is any thing wrong with using Object.freeze if you really > need to return an immutable object. But what's wrong with returning a fresh > object each time? Are these operations highly likely to be used in > performance critical loops. If not, trying to share a result object sounds like > premature optimization. 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.)
Received on Tuesday, 29 October 2013 00:26:45 UTC