Re: Datatypes in Plc4j

2018-08-02 Thread Sebastian Rühl
Sorry for the typo, I actually meant Julian (I blame the MBP 13’’ keyboard for that ;) > Am 02.08.2018 um 09:54 schrieb Sebastian Rühl > : > > Hi Julia,

Re: Datatypes in Plc4j

2018-08-02 Thread Sebastian Rühl
Hi Julia, +1 for a JPA style on top addition on plc4x . In addition to the comments from Chris: We had a discussion on this topic a while ago here https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E

Re: Datatypes in Plc4j

2018-07-31 Thread Christofer Dutz
Hi Julian, Glad we're on the same page here :-) feel free to create such a ticket. Chris Am 31.07.18, 12:42 schrieb "Julian Feinauer" : Hey Chris, I get your point regarding reading "basic" types and I agree. And the idea with the mapping I

Re: Datatypes in Plc4j

2018-07-31 Thread Julian Feinauer
Hey Chris, I get your point regarding reading "basic" types and I agree. And the idea with the mapping I had was indeed meant not directly on the plc level but as you outlined one level above where plc4j takes care of generating a suitable set of requests and assembles the struct for the resu

Re: Datatypes in Plc4j

2018-07-30 Thread Christofer Dutz
Hi Julian, Well the reason for this was to allow explicit generic handling of the responses. There had been quite a lot of refactoring regarding this in the early times of PLC4X. I do agree that it limits the extensibility but I remember in the beginning we even had hard coded types so

Datatypes in Plc4j

2018-07-29 Thread Julian Feinauer
Hi all, After going through the code I have one question about the “Typesystem”. From what I see, currently the java class(-name) is used as type parameter. Is there a specific reason for this? I am asking because this limits, in my eyes, the extensibility of the typesystem massively, e.g., for d