> On 29 Mar 2017, at 10:22, Peter Levart <peter.lev...@gmail.com> wrote: > > Hi Chris, > > On 03/29/2017 06:06 PM, Chris Dennis wrote: >> Remi: I really have to squint pretty hard to see that as anything other than >> “brute-force” - it’s still an O(N) calculation. >> >> Paul: Right - but if I’m trying to implement the Streams API directly thats >> pretty much a non-starter, right.
Agreed. >> I think at this point the simplest change here would be to remove the final >> modifier from the accessor methods on the classes. That way I can unmarshal >> in to a subclass that overrides the accessor methods (and makes the combine >> and accept methods throw UOE). That obviously limits what can be done with >> the resultant instance, but it at least allows for a useful “read-only” >> behavior on return from a terminal stream operation. It might also be >> possible to retain some of the combine functionality if the base methods >> accessed state through the instance methods rather than directly but that >> would not be “required” (and would be complicated in the case of Double). > > An alternative would be to introduce a protected constructor taking (count, > sum, min, max) parameters so that a serializable subclass could do the > following: > Yes, you beat me to replying (the thought occurred while i was cycling to work :-) ). Although i would argue a public constructor is just fine, which also performs some simple checking of the arguments. Paul.
