Split parameters between start() and constructor

[alexshalamov]

There are two types of information that might be required by the Sensor object: construction parameters that are persistent during the lifetime of a sensor and parameters that web developer can change after sensor is constructed. By moving SensorOptions to the start() method, Generic Sensor API would allow web developers to change e.g. frequency hint for the sensor without the need to re-construct the object.

Example:

// Construction parameters that are immutable during sensor's lifetime.
let gyro = new Gyroscope({uncalibrated: true});

// Platform selects default frequency hint.
gyro.start();
gyro.stop();

// Provide 30Hz frequency hint.
gyro.start({frequency: 30});
gyro.stop();

[tobie]

From a developer experience perspective, I don't think that's an optimum solution, as now you have to figure out whether your option is immutable or not.

Given extra options won't throw, developers won't even figure out what's going on if they make a mistake here. For example, the below would default to the implementation specific default, and finding out about that would require inspecting the timestamps, storing and comparing them.

let gyro = new Gyroscope({ frequency: 60 });
gyro.start();

Similarly, in the following scenario, the developer might expect the frequency set earlier to stick:

let gyro = new Gyroscope();
gyro.start({ frequency: 60 });
gyro.stop();
gyro.start(); // what's the frequency here? 60 or DEFAULT?

For these reasons, I believe an option maybe based on exposing a frequency attribute or a dedicated .setFrequency(freq) method might be better. We should investigate it as part of level 2.

[anssiko]

This issue discusses a generic solution to change parameters after the sensor is constructed, of which #63 was a special case of. Since the group did a decision to defer #63 back to Level 2, also this generic issue logically follows that decision.