How do you do the same thing when modifying a local variable? You might try making a copy, modifying that, and then assigning back, but that's boilerplate, and it's easy to get wrong. Worlds are a more primitive mechanism that would be baked into a language, such that building a generic transaction api for local actions on top of worlds would be trivial. The fact that it could look exactly like the transaction api that you currently know and love for remote resources is a feature.
Ok... maybe it's because I like to program the functional way (in imperative languages), but I've never found a reason to rollback local variable changes. That's because local variables don't "fail" and don't need to be rolled back. I see why it's a nice solution but I've never really seen the problem.
What I normally do is: operate on temporaries (or copied parameters), change remote resource (it's safe to just rollback resource changes and exit here in case of problems), then change "the state" when operations cannot fail any more. Is there any real-live problem that needs local variables rollback? (that is shorter / nicer than returning the result from temporary locals) I'd really like to see it.
It's a heavily researched topic right now. The Worlds concept, as far as I can tell, is actually more general than STM and what you described. In STM, there's the global state everyone can see, and then there's local states that try to commit atomically to the global state. With Worlds, I don't think there's one true global state. I think it would give you more explicit control, which I'm not convinced would be a good thing.
The Worlds concept, as far as I can tell, is actually more general than STM and what you described
Where in my comment did I describe Worlds in a limited way? I just gave one small example of one possible application of them, in reply to a comment specifically about their relationship to transactions.
