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