[Base] Handling of read/write field items

[Christofer Dutz <ch...@c-ware.de>]

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