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.
The original intent of CME, from my recollections back in lead-up-to-Java-5 days, was to prevent iterators from breaking i.e. throwing exceptions, due to the occurrence of the "concurrent" operation that changed the structure. It was not intended as an indicator of a semantic programming error. Replacing one element whilst there is a live iterator can be just as semantically wrong as replacing them all.
CME, iterators, and the fail-fast concept were introduced in JDK 1.2 with the Collections Framework. The platform has evolved a LOT since then, so I don't think it's worthwhile to make a stand on original intent. The wording around CME and fail-fast is very pragmatic, so it sense to be pragmatic about this issue.
s'marks
