- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Mon, 28 Oct 2013 17:18:02 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Oct 28, 2013, at 4:43 PM, Boris Zbarsky wrote: > ... > This came up today in a discussion of how we want to implement https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html in Gecko, and specifically how to implement the "axes" and "buttons" attributes on <https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#gamepad-interface>. Our current implementation returns vanilla JS arrays, but returns a new one every get, which is pretty suboptimal. So we were considering changing them to some ArrayClass interface and thinking about what issues that might cause for callers... On Oct 28, 2013, at 4:54 PM, Jonas Sicking wrote: > Lets just return a frozen Array. I know that people on TC39 has said > that it's ugly, but I still think it's far less ugly than creating a > whole pile of host classes just because we lack immutable arrays. Those really are the two options if you don't want to create a communications path between clients, either return a fresh object to each time or have a single immutable object that is returned. 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. Allen
Received on Tuesday, 29 October 2013 00:18:40 UTC