This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27549 - Support holes or undefined values in the sequences as return values?
Summary: Support holes or undefined values in the sequences as return values?
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 26181
  Show dependency tree / graph
 
Reported: 2014-12-09 17:25 UTC by Olli Pettay
Modified: 2014-12-09 18:59 UTC (History)
5 users (show)

See Also:

Attachments

Description Olli Pettay 2014-12-09 17:25:22 UTC 
Gamepad spec might want to be able return sequences which have holes.
sequence<optional FooBar> as a return value could be quite readable.
Comment 1 Domenic Denicola 2014-12-09 17:26:45 UTC 
HOLES ARE EVIL.

Just use undefined instead?
Comment 2 Boris Zbarsky 2014-12-09 17:30:12 UTC 
> HOLES ARE EVIL.

Tell that to UA authors, who all produced arrays with holes here.  :(

But yes, we could just make it undefined; still need IDL syntax for it, ideally.
Comment 3 Olli Pettay 2014-12-09 17:33:50 UTC 
sequence<optional FooBar> leading to an array which doesn't have holes but just
values defined to be undefined would be ok to me.
Comment 4 Ted Mielczarek [:ted] 2014-12-09 18:59:51 UTC 
Olli filed this bug after discussing bug 27549. Right now implementations are mixed on what to do with removed devices in the return value of getGamepads. Firefox returns an array with nulls where they used to be, Chrome returns a GamepadList which does not have the indicies of removed devices as properties (hasOwnProperty returns false for removed indicies), and IE returns a thing that claims to be an Array but also acts the same way (does not have properties for removed indicies). bug 26181 comment 5 describes the behaviors there.

I'm okay with changing the spec as long as we can change it to say something that makes sense in terms of web standards, and also isn't incredibly different from current implementations.