On Thu, Jul 31, 2014 at 12:55 PM, Aaron McCurry <[email protected]> wrote: > We could do that, however we likely would need a way to have the > implementation create a initial return object so that a merge could be > incremental. > > For example: > > Let's say that we are aggregating counts and we have a custom Counts object > and we are going to merge each Result as it finishes. > > public Counts merge(Counts existing, Result result) { > Counts mergedCounts= new Counts(); > // Do some counting and merging of existing Counts. > return mergedCounts; > } > > So we could do one of three things. We could allow existing to be null if > it's the first merge call or we could have a second method that doesn't > take an existing argument. > > public Counts inital(Result result) { > ... > } > > The last option I see is to use vargs like: > > public Counts merge(Result result, Counts... existing) { > Counts mergedCounts= new Counts(); > // Do some counting and merging of existing Counts. > return mergedCounts; > } > > This is at least a little cleaner in that it's implied that existing could > be absent or null as well as allowing multiple items to be merged are the > same time. > > What do you think?
Yeah, they feel kinda awkward... what about having the command hold it's state internally, then merge(Result r) is asking to merge r onto itself? Thanks, --tim
