[GitHub] [plc4x] splatch edited a comment on pull request #201: PLC4X-252 Support passing of PlcField in subscription builder.

[GitBox <gi...@apache.org>]

splatch edited a comment on pull request #201:
URL: https://github.com/apache/plc4x/pull/201#issuecomment-745244392


   > If a user uses the driver module directly and directly instantiates the custom driver field types, then his code is no longer portable
   
   That's user decision how he uses library and not ours.
   
   Present API in 0.8 does not expose types such as `S7Connection` or `CANopenConnection` which could be used with specific field types. Even if that would be a case there is still a pooling connection which will bring yet another type to the stack.
   
   I do instantiate fields directly in openhab bindings cause by this way I can assure that it compiles against next PLC4X releases and does not depend on changing field syntax. While PLC4X offers universal APIs the openHAB layer built on top of it provides driver and field specific configuration options. For example here you can find an updated discovery logic for one of canopen devices supported by binding:
   https://github.com/ConnectorIO/connectorio-addons/commit/29c53778791796c642c9011d9adcac0e36376e39#diff-f498576d3c3ecc8a6206f7b7327ef608c0e05441b5c6ae8afcd274d5e47eebcc
   
   Keep in mind that passing strings involves regular expressions which proved to cause minor, but still, failures. See PLC4X-56, PLC4X-194. Gluing a string with specific field syntax just to pass it to specific driver is simply redundant and subject of additional friction when migrating to future releases (when field syntax changes it goes under compiler radar).


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org