Hi Julian,
please let me repeat how I understood your proposal:
You observed that in multiple drivers the conversion between byte-array data to
the actual Java type is pretty similar and would like to wrap that mapping code
in some commonly shared code base?
I agree ... if a float is transformed as IEEE 754 Floating Point, it doesn't
matter what driver this belongs to. But on the other side the code for doing
this conversion too isn't that complex.
I think in this case eventually even a class with static methods should be
enough... sort of
public static float parseIEEE754Float(byte[] in);
public static int parseLE32BitInt(byte[] in);
...
Maintaining a registry component that has to be injected into the drivers of
type conversions where drivers can register custom converters sounds a little
overkill to me.
If a driver requires other conversions, it can implement them itself and if it
makes sense to add them to the driver-base version, that code is simply moved
there.
What do you think?
Chris
Am 17.08.18, 14:14 schrieb "Julian Feinauer" <[email protected]>:
Hey al,
I like to open another discussion as I am currently working on another
refactoring of the Drivers, namely the extraction of "binary" encoders and
decoders as common concern. After our discussion about the addition of the
binary representation to the S7 driver I observed that several drivers use very
similar code to transform java types to byte representations of specific flavor
(Big Endian, ...).
Thus my aim is to provide a “library” of common encoders and decoders
between Java Types and byte representations that every driver can use but also
register custom Java Types and their representation (as it is e.g. needed for
ADS, I think).
Do you agree with this?
Julian
