We have a use case where we expect a Double but unfortunately, the data is not always consistently provided to us from the 3rd party, as it sometimes comes in as "capital": 3.4 and other times as "capital":3 (when the double is precise it becomes an int).
We obviously want to read a Double in our code, but Klaxon fails when trying to read "capital":3 because that's being parsed as an int, and there is only a cast instead of conversion to double:
fun double(fieldName: String) : Double? = get(fieldName) as Double?
This fails with java.lang.Integer incompatible with java.lang.Double
Looking at the int() and long() methods we see that they check whether the value is number and do and explicit .to<Type>. I was wondering if this is something that Klaxon should be doing with the other number functions?
In other words, instead of
fun double(fieldName: String) : Double? = get(fieldName) as Double?
to have
(get(fieldName) as Number?)?.toDouble()
Happy to write a PR and some tests for this if that helps.
I have a similar issue where I sometimes get values like coordinates=["12.23", "23.34"], and those are ending up in my data class as strings (but they are defined as a list of Double values).
We have a use case where we expect a
Double
but unfortunately, the data is not always consistently provided to us from the 3rd party, as it sometimes comes in as"capital": 3.4
and other times as"capital":3
(when the double is precise it becomes an int).We obviously want to read a
Double
in our code, but Klaxon fails when trying to read"capital":3
because that's being parsed as an int, and there is only a cast instead of conversion to double:This fails with
java.lang.Integer incompatible with java.lang.Double
Looking at the
int()
andlong()
methods we see that they check whether the value is number and do and explicit.to<Type>
. I was wondering if this is something that Klaxon should be doing with the other number functions? In other words, instead ofto have
Happy to write a PR and some tests for this if that helps.