On Wed, May 16, 2018 at 11:25 AM, Stuart Marks <stuart.ma...@oracle.com> wrote:
> > > On 5/15/18 7:37 PM, David Holmes wrote: > >> I'm still with Martin on this. It makes no sense to me to allow replacing >> one element to not cause CME, but replacing more than one does cause CME. >> This is inconsistent and confusing and the end result is the programmer >> won't know what to expect when or why. >> > > This is the fallacy of composition, that if a single operation has some > property, then an arbitrary composition of those operations must also have > that property. This is decidedly not true for many things. Consider > atomicity for example. My claim is that the setting of an individual > element is qualitatively different from a bulk operation. > (We don't seem to be moving towards consensus ...) atomicity is "obviously" a non-composable property of an operation, but contrarily "does not modify" is "obviously" composable. Having replaceAll increment modCount is almost as wrong as having forEach increment modCount, even though """forEach is qualitatively different from get().""" Incrementing modCount is introducing a subtle race into plausible user code that would otherwise be correct. At the very least, having replaceAll increment modCount (inconsistently!) is surprising to users and is not documented anywhere.
