Re: [Gamepad] Liveness of Gamepad objects

On Wed, Apr 30, 2014 at 7:11 AM, Ted Mielczarek <ted@mozilla.com> wrote:

> On 4/29/2014 10:39 AM, Ted Mielczarek wrote:
> > The only major issue that needs to be fixed in the Gamepad API spec
> > currently is the liveness of Gamepad objects[1].
> After reading through the discussion here I'm leaning towards specifying
> the snapshot behavior that Chrome implements. Regardless of whether we
> spec an event-based update mechanism in the future, being able to refer
> to a snapshot of Gamepad state seems useful, and there's not much
> overhead in calling navigator.getGamepads()[i] instead of referring
> directly to a saved Gamepad object.
>
> My only reservation is that if Gamepad becomes a snapshot instead of a
> live object, it feels weird to suggest adding output methods to it (like
> adding vibration support). Perhaps I'm overthinking it, though.
>
> Any other thoughts here?
>

I agree with this concern.


Another argument for "live" objects is that it should be possible to reason
about gamepad objects as instances of a Gamepad constructor. The "snapshot"
design destroys any notion of object identity that could be associated with
a gamepad object.

Consider the case where a WeakMap is used to store some side table of
information:

// Live object use...
var wm = new WeakMap();
var gamepad = navigator.getGamepads()[0];

// store some foo counter state
wm.set(gamepad, { foo: 1 });

// later access the foo count (some other aspect of the program has been
updating it)
wm.get(gamepad).foo;


There is no analog in the snapshot case because "gamepad" will be a new
snapshot object every rAF turn, since the reference is lost the WeakMap
will dispose of the key/val pair and the side-table state disposed along
with it.

Rick