No problem - it certainly feels like we have been round in circles a few times on this ;)
On 1 August 2011 20:47, Greg Brown <gk_br...@verizon.net> wrote: > Oh, OK. I thought you were offering that as an argument against implementing > Group. Sorry. > > On Aug 1, 2011, at 9:34 AM, Chris Bartlett wrote: > >> Um, I'm not suggesting that it shouldn't be a Group. My point was >> that it merely being a Group doesn't tell the whole story about how >> the tasks might get executed. That is where a bit of documentation >> comes in handy. >> >> On 1 August 2011 20:26, Greg Brown <gk_br...@verizon.net> wrote: >>>>> I think the strongest argument for Group is that allowing duplicates >>>>> could result in confusing behavior. Making it a Group ensures that the >>>>> intent is clear. >>>> >>>> Making it a Group certainly helps with the intent, but wouldn't >>>> eliminate confusing behaviour entirely as my example of the >>>> 'SingleThreadExecutor' suggests. Better that just accepting a >>>> Collection / Iterable / Array or whatever. >>> >>> True, but it would help eliminate confusion for the common case. I think a >>> more important question is - what do you lose by enforcing uniqueness? The >>> only thing a Sequence would allow you to do is ensure that a given task >>> type is executed in series while all other tasks are executed in parallel, >>> which seems like a pretty narrow case. It is also something that can be >>> implemented at the application level for any app that might actually need >>> it. >>> >>> G >>> >>> > >
