Re: WET vs DRY tests

2018-02-19 Thread Christofer Dutz
Have to agree that I am having problems to understand what the thing does. But that might be related to me not having had my first coffee if the day yet ;-) Chris Outlook for Android herunterladen From: Justin Mclean

Re: Batch reads with JPA like annotation magic?

2018-02-19 Thread Niclas Hedhman
Being the Overlord of Magic that can be done in Java, I have some comments to make on this idea. 1. In principle what you suggest can already be done quite easily in Apache Polygene, by creating a "generic mixin" that overrides the generic PropertyMixin. Polygene is probably way more powerful

tests and coverage

2018-02-19 Thread Justin Mclean
Hi, It looks to me that some of the tests are just here to increase coverage and we seem to be missing unit test for some of the more simple classes. Perhaps there’s a bit too much focus on the happy path and we’re not always checking boundary conditions and the like. Obviously this is a good

WET vs DRY tests

2018-02-19 Thread Justin Mclean
Hi, Was just looking at some of the new tests and just wondering if they are trying to be a bit too clever? What do other people think? For instance this: @Test public void testOfWintime() throws Exception { assumeThat(clazz, isOneOf(TimeStamp.class)); { Method ofMethod =

Re: Batch reads with JPA like annotation magic?

2018-02-19 Thread Christofer Dutz
Hi Dale, The direction thing was inspired by the way the Beckhoff ADS protocol was designed. There they sometimes Send Data alongside read requests and sometimes have strange "return what's in there and then overwrite with this" type of requests. The Beckhoff support guy mentioned that they

Re: Give readRequestItems a "name" property?

2018-02-19 Thread Christofer Dutz
Hi Dale, for a test I simply added "name" as name for the item and it seems to work nicely without increasing complexity of the API. However splitting up into Single and Batch is difficult as for single we would have to split up to Singe, Array and Batch. Which blows things up quite a bit. I

Re: Eggent provider for batch reads?

2018-02-19 Thread Dale LaBossiere
> On Feb 19, 2018, at 9:52 AM, Christofer Dutz > wrote: > > Hi Dale, > > well regarding your suggestion ... well an address is sort of just the > starting point, you still need a type and size to fully qualify a request. > And another thing is, if we did it this way

Re: Give readRequestItems a "name" property?

2018-02-19 Thread Dale LaBossiere
Right a name isn’t really required for the single-item-request case. Not sure that requiring one is that big of an imposition though and I suspect it will make an app clearer even in that case. I know some of this was hashed over a while ago but maybe there should be different classes for

Re: Batch reads with JPA like annotation magic?

2018-02-19 Thread Dale LaBossiere
Doesn’t the user need access to the response code for each annotated item? I’m unclear on why a Direction is needed/desired. Is it just for “documentation" of what is possible for an item at that address? Maybe it would be checked when the annotated class is used in a Read vs Write request to

Re: Give readRequestItems a "name" property?

2018-02-19 Thread Christofer Dutz
But I already did notice that there are drawbacks with mandatory names ... the single value Edgent suppliers for example ... here I need to set a name, even if it's not needed and implicitly given by the pipeline I am plumbing together ... Chris Am 19.02.18, 16:39 schrieb "Christofer Dutz"

Re: Give readRequestItems a "name" property?

2018-02-19 Thread Christofer Dutz
Hi Dale, I agree ... we should make it mandatory. Let's hear what the others have to say. Chris Am 19.02.18, 16:23 schrieb "Dale LaBossiere" : I think I’m generally +1 on this, though I think *optional* names may just make it harder / less predictable to use these

Re: Eggent provider for batch reads?

2018-02-19 Thread Christofer Dutz
Hi Dale, well regarding your suggestion ... well an address is sort of just the starting point, you still need a type and size to fully qualify a request. And another thing is, if we did it this way the information address, type and size would be duplicated a huge amount of time and would have

Re: Eggent provider for batch reads?

2018-02-19 Thread Dale LaBossiere
Hmm… looks like this never really got sent by by my system :-( Sending it again and then follow up on Chris’s recent mail on this topic. — Dale > On Feb 5, 2018, at 6:03 PM, Dale LaBossiere wrote: > > >> On Feb 5, 2018, at 5:43 AM, Christofer Dutz

Give readRequestItems a "name" property?

2018-02-19 Thread Christofer Dutz
Hi all, I’m currently whipping up a first POC for usage on a real machine (Not just our companies Christmas tree) ;-) While at it, I did notice again what I had noticed a few times before: It would be cool if we could assign a “name” or “alias” to a request item. With this for example I could

Re: Does this seem odd to you?

2018-02-19 Thread Christofer Dutz
Ok ... fixed that __ Thanks again for finding ( Chris Am 17.02.18, 09:43 schrieb "Christofer Dutz" : If it's code I have written, it was a mistake ... I would agree to use the exception and not the assertion, because they can be turned off. Chris

Re: First Beckhoff Information System TwinCAT ADS/AMS implementation

2018-02-19 Thread Christofer Dutz
Hi All, first off all, thanks for your work on the Beckhoff protocol. I don't think that moving the encode/decode code into an abstract base class. However moving them into a utility sounds more like an idea. I think with "prefix them with endianness" you would mean something like one class