W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

Re: ArrayClass should imply @@isConcatSpreadable

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 28 Oct 2013 17:18:02 -0700
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-Id: <F233285A-3C54-4650-988E-59403995C31B@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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.

Received on Tuesday, 29 October 2013 00:18:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC