W3C home > Mailing lists > Public > public-webevents@w3.org > October to December 2011

Re: [gamepad] .gamepads vs. function access

From: Paul Bakaus <pbakaus@zynga.com>
Date: Thu, 20 Oct 2011 08:23:01 -0700
To: Vincent Scheib <scheib@google.com>, Scott Graham <scottmg@google.com>
CC: "public-webevents@w3.org" <public-webevents@w3.org>
Message-ID: <CAC60916.104F2%pbakaus@zynga.com>
We have stuff in the DOM that triggers layout like offsetWidth, so I don't mind implicit polling by accessing .gamepads. Key is to document and spread this knowledge. In a time where we have getters and setters in JS, things become confusing if not well documented.

Von: Vincent Scheib <scheib@google.com<mailto:scheib@google.com>>
Datum: Tue, 18 Oct 2011 23:42:57 -0700
An: Scott Graham <scottmg@google.com<mailto:scottmg@google.com>>
Cc: "public-webevents@w3.org<mailto:public-webevents@w3.org>" <public-webevents@w3.org<mailto:public-webevents@w3.org>>
Betreff: Re: [gamepad] .gamepads vs. function access

pollGamepads() to me implies that the data would be refreshed by me calling the function, which may be misleading if that's not the case.

.gamepads and .getGamepads() feel roughly equivalent in meaning to me, though the former easier to write and read.

I could see code with the intent, "go check the gamepads and see if anything new has happened". But I think a check for changed timestamps should suffice there. IMHO the name doesn't need a fix.

On Tue, Oct 18, 2011 at 10:58 AM, Scott Graham <scottmg@google.com<mailto:scottmg@google.com>> wrote:

Currently, the gamepad spec says it's navigator.gamepads to get
polling-style access to the gamepad data.

In writing some sample code, I'm finding it feels a bit odd because
you don't know when the data is updated.

I'm inclined towards "navigator.pollGamepads()" or maybe
"navigator.getGamepads()" to make it more clear that you're getting a
copy that's (hopefully) up-to-date at that point.

Any positive or negative feelings on that?

Received on Thursday, 20 October 2011 15:23:33 UTC

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