search

milesburton / Arduino-Temperature-Control-Library

Arduino Temperature Library
https://www.milesburton.com/w/index.php/Dallas_Temperature_Control_Library
974 stars 486 forks source link

Q: 4.0.0 - drop Fahrenheit specific functions and constants ? #187

Closed RobTillaart closed 2 years ago

RobTillaart commented 3 years ago

As the interface grows a lot by supporting all Fahrenheit versions of functions and constants. I propose to drop these.

Major reason is that the Fahrenheit constants tend to become floats which are harder to compare on equality. Furthermore the conversionC to F is straightforward for the user.

Opinions?

karlg100 commented 3 years ago

A quick glance, and it seems most other temp related libraries have some kind of way to convert. Just keep on par, and I think you'll find many users rely on conversion - it may be hard to remove.

But I do agree, comparing F vs C is much harder, especially when looking for error values.

Perhaps just some small rewrites to make the library itself function on C exclusively, but perhaps a support function to convert from C to F mathematically only, and force the user to pass the value of C into the function.

The supporting conversion functions could even be moved to a separate include file to keep them separate and out of the main library.

RobTillaart commented 3 years ago

the constants

The comparison of the constants that are float is caused by the fact that the library handles an error value to a temperature.

The sensor returns the temperature XXX (-127?) as NO_TEMP_ERROR_C (whatever). Because it is communicated through the temperature registers the lib processes it as a temperature, causing it to have a NO_TEMP_ERROR_RAW, NO_TEMP_ERROR_C and NO_TEMP_ERROR_F versions.

The library should use only a single NO_TEMP_ERROR and propagates this explicit as an error. Then the value would not go though the e.g Celsiu2Fahrenheit conversion. So there would be no three variations of the same flag, and the library would not have the "difficult" float constants anymore.

This would also make the error code sensor independent.

the Fahrenheit functions

As most / all (?) of these are wrappers this more a maintenance optimization as that is a real issue. Karlg100 has a good point that many users rely on this so removing would cause more problems than it solves.

The conversion functions might include ToKelvin() functions as Kelvin is used e.g. meteo applications.