Hi all,
while working on the API refactoring I initially thought to save the values in
the readresponse/writerequest items in the exact format the driver sends out,
but it turns out that it makes things even more complicated.
So I thought of an alternative:
I added a set of different item types (in the driver-base so generally hidden
from the user) (The type in brackets is the type used to internally save the
value):
* BooleanFieldItem(Boolean)
* FlotingPoiontFieldItem(Double)
* IntegerFieldItem(Long)
* StringFieldItem(String)
* TimeFieldItem(LocalDateTime)
Also I changed the “is{Typename}” methods into “isValid{Typename}” as the value
might actually not be a short, but could be cast to short as the value is not
outside of the value range of a Short.
* For BooleanFieldItem only “isValidBoolean” will return true (except if
the value is “null”).
* For IntegerFieldItem and FlotingPoiontFieldItem the same rule applies ...
if you try to getBoolean for an item, this will be true if the value is “not
0”, in its 0 then getBoolean returns false
* The other isValid{Typename} do a check first, if the value would fit
into a smaller type and only return true if it would fit.
* All numeric getters simply use the Java built in converters to provide
casted values such as “Long.doubleValue()” after doing a check if the type
would fit.
* The string and date functions simply say it’s not a valid type.
* Sting and Time both don’t support getting numeric or Boolean values.
Now a driver will decode it’s values into the default types and populate the
response with instances of these FieldItems and the client can access
information as needed.
This is a minimal overhead when reading a lot of small numeric values, but I
think it’s an overhead that doesn’t weigh that much, that it’s worth
implementing a super minimal type system.
Chris
