Re: [sensors] Future proofing terminology

> All that to say that the reporting frequency is a function of the sampling frequency and not the opposite.

Absolutely agree, and it is reflected in the [abstract operations]( 

The problem as I see it now (and thanks for pointing it out!) is an unfortunate name and definition of the [Sensor.requestedReportingFrequency]( internal slot. Now it might give a wrong impression that it is only to define [reporting frequency]( , actually this slot stores the `frequency` option and its value is used for these two things:
1) (indirectly) set the [requested sampling frequency]( for the associated platform sensor.
2) set the [reporting frequency](  for the given Sensor object (in practice it sets the upper limit because `reporting frequency` is always capped to `sampling frequency`).

I will rename the slot to `frequency` (so that it reflects the ctor option name) and provide a better description to avoid this confusion.

GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at using your GitHub account

Received on Friday, 29 September 2017 10:34:34 UTC