This document:Public document·View comments·Disposition of Comments·
Nearby:Device and Sensors Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-2900
There are 1 comments (sorted by their types, and the section they are about).
I really don't like that the Vibration API assigns meaning to the numbers in lists handed to it based solely on the oddness of their indices. This means developers have to be incredibly careful to only ever extend their lists two items at a time or risk subtle, difficult-to-track-down bugs. One solution would be to create lists of lists of [activeTime, restTime], but even this creates a situation where future extensions of the API would have to run on top of a completely different interface. >From my perspective, the *right* way to do this, while a little more verbose, would be much more extensible and much more explicit; have the thing take a list of vibration objects formatted something like {time: [number], vibrate: [bool]}. This means you don't have to keep track of the index of every item you append to your list and you open the door to future parameters such as intensity or, who knows, motor selection in hypothetical multi-vibration-motor devices. It would, of course, be possible to support all three of these interfaces, if so desired.
Add a comment.