Goode evening, I removed the reference and pushed to master. The current changes got also merged into the PLC4X-12 branch and is in working state.
Enjoy the evening, Mark > Am 12.01.2018 um 18:04 schrieb Christofer Dutz <[email protected]>: > > +1 for not having a reference from the request to the response. > > Chris > > Outlook for Android<https://aka.ms/ghei36> herunterladen > > > > Von: Mark Keinhörster > Gesendet: Freitag, 12. Januar, 17:27 > Betreff: Re: Generify branch > An: [email protected] > > > Hi Sebastian, cool that looks a lot cleaner than before, thank you so much! > :) As I try to merge the changes into the Scala branch, there is one last > point to discuss: Do we really need the PlcRequest reference the response? I > can relate to it in terms of convenience but it looks quite ugly to me for > the following reasons: 1) The two classes (Response/Request) are really > tightly coupled which is not necessary as we can „navigate“ back from > response to request 2) We got mutable state in the request item which is not > functional and I would hesitate to implement it that way in Scala 3) The > behavior gets quite messy when a RequestItem instance is used multiple times > (which right now is viable and not prohibited) Just one example: Sending an > item a second time leads to a non-updated request item as the response item > won’t be null anymore. Experience has shown me that constructs like this lead > to really hard-to-find bugs, but I am open for discussion. @Chris what do you > think? Sorry for nagging again... again a big thanks for the clean-up! Mark > > Am 11.01.2018 um 15:35 schrieb Sebastian Rühl : > > Hi all, > > I could > cleanup a lot in the refactoring/java_generify branch. > > First of all > thanks for the feedback of Chris and Mark I could simplify this by a great > deal. > Now we just have additional TypeSafePlc* requests. > The convenience > methods are integrated into the normal request classes. > > As the changes > are now minimal im going to merge this branch into master. > > Regarding the > builders: My preference would be to encourage the use of them and limit the > visibility of the constructors. However as these are optimizations we could > look at this after that. > > Sebastian >
