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 <[email protected]> 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 > >
