Hey Andrey, One thing that would stand against this: Adding a execute() would make the PlcReadRequest mutable which is a thing we should avoid (Mutable because it would need a reference store to something that can handle the execute).
FYI: I added a mutability test into plc4j-api (which should be added to plc4j-driver-bases after the refactoring) which tests all Items for mutability. Currently we have some open issues regarding that. Sebastian > Am 12.09.2018 um 14:50 schrieb Andrey Skorikov > <[email protected]>: > > Hello, > > currently, PlcReadRequests and PlcWriteRequests are executed by invoking the > corresponding read/write operation on the PlcReader/PlcWriter objects. Hence > the typical workflow for reading a value contains the following steps: > > 1. Obtain a PlcReader instance from a PlcConnection > 2. Obtain a Builder by invoking readRequestBuilder() on PlcReader > 3. Build a request using the Builder > 4. Execute the request by invoking read() on the PlcReader, passing the > constructed request as argument > > PlcReader reader = ... // obtain reader > PlcReadRequest request = reader.readRequestBuilder().addItem(...).build(); > Future<PlcReadResponse> response = reader.read(request); > > Since we only can build a request throgh a PlcReader instance, invoking the > read operation on the PlcReader is redundant. Therefore I suggest removing > the read/write operation from the PlcReader/PlcWriter and defining a > execute() operation on PlcRequest instead. The workflow would look like this > then: > > PlcReader reader = ... // obtain reader > PlcReadRequest request = reader.readRequestBuilder().addItem(...).build(); > Future<PlcReadResponse> response = request.execute(); > > Please note that there is no more need to "keep" a reference to PlcReader in > this context, since it is implicitly associated with the request by calling > reader.readRequestBuilder().build(). > > Best regards, > Andrey >
