>I'm talking about within a single method, which inherently means belonging to a single thread
If your method is modifying data non-atomically, then you can still have issues with data consistency when another thread attempts to access the object in the middle of your update. You're going to need to synchronize access in some manner.
>Some language constructs are just bad...checked exceptions...
Checked exceptions are not an integral part of OO design. Objects, along with the concept of properties (i.e. state) are.
>more restrictive models really are easier to understand
> If your method is modifying data non-atomically, then you can still have issues with data consistency when another thread attempts to access the object in the middle of your update.
Externally-visible data should not be mutable.
> That's simply not a universal truth.
Let's talk specifics then. My preferred model is: every piece of persistent (beyond a single method scope) mutable state is owned by an actor, and accesses to that state are performed by sending State values to that actor and receiving values back. The type system enforces that any state modification happens in the appropriate actor; since State is an ordinary value you can refactor safely without worrying that you're changing concurrency boundaries. Monadic syntax (for/yield) makes it easy to compose state changes that should happen atomically, and since the call to actually perform the modification is explicit, it's easy to see which changes are atomic and which are not.
This doesn't automatically solve the problem. If two threads invoke methods which mutate (or read) the internal state, then inconsistencies can result if not properly synchronized.
>Let's talk specifics
You originally stated that more restrictive models are easier to understand. My point is not that they never are (as in some universal truth). It's that the real answer is that it depends. And, in the context of this discussion, simply declaring that the restrictions that immutability imposes are automatically beneficial to understanding is a non-sequitur.
But, WRT to the specifics you provided, your model may indeed provide structure that can aid in understanding the code. But, I don't think it's the degree of restrictiveness that determines this, as much as that there is some model in the first place. Of course, whether it's the best choice in a given situation is a relative proposition.
Interestingly, however, you allow for mutability. And the real "magic" is happening not through immutability alone, but careful assignment of mutability operations in conjunction with other concurrency idioms that you expect to overlay atomicity.
So, essentially we agree: declaring mutability as the root of all evil is overkill. Instead, the real prescription relies upon carefully considered/managed mutability, used with the language's intended concurrency features.
If your method is modifying data non-atomically, then you can still have issues with data consistency when another thread attempts to access the object in the middle of your update. You're going to need to synchronize access in some manner.
>Some language constructs are just bad...checked exceptions...
Checked exceptions are not an integral part of OO design. Objects, along with the concept of properties (i.e. state) are.
>more restrictive models really are easier to understand
That's simply not a universal truth.