plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject [Base] Handling of read/write field items
Date Mon, 03 Sep 2018 09:20:32 GMT
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message