On Wed, Apr 30, 2014 at 5:58 AM, Ted Mielczarek <[email protected]> wrote:
> Yes, it's true. In any event, this is going a bit afield. We're not going > to spec events for the first version of the spec. > Examining the features that each design would make easier or harder isn't afield. On Wed, Apr 30, 2014 at 6:11 AM, Ted Mielczarek <[email protected]> wrote: > 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. > I cut out a comment about that for length, actually. It would be better to have separate objects for the gamepad itself and where output methods live, and another interface holding a snapshot of an input state. Then, you'd just call gamepad.getState() to read the state for that device. It's also a natural place for an event interface to live, and for input state that doesn't change, like the device's ID. I definitely wouldn't make Gamepad live just to avoid doing that, though. It could always be added later, by adding a GamepadDevice interface, eg: gamepadDevices = navigator.getGamepadDevices(); gamepad = gamepads[0]; state = gamepad.getState(); equivalent to navigator.getGamepads()[0]. -- Glenn Maynard
