I’d actually claim that actors are the most true to the actual intent and principles behind OOP, and the fact that you can grab innards of a class and do a += 1 on it is the doing model “breaking“.
Turns out actors outright ban such loose treatment of the model — encapsulating is enforced and what previously sloppy accessing another objects inner state you could have gotten away with, now you don’t.
This goes all the way back To Allan Kay terming the term “object” and OOP and SmallTalk, and a pretty interesting response he wrote in 1998.
I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.
The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase).
—
But anyway, in practical terms looking at all this from the perspective of “what it looks like to be doing” and “what it’s actually doing” is helpful imho. both the await other.balance = other.balance + something.balance as well as chained writes which are quite scary IMHO such as: someActor.anotherActor.something = bla are IMHO very difficult to understand what kind of transactionallity we’ll be getting here. And the answer is going to be “almost no guarantees, this code is very likely broken”.
Because mutations often are more than a trivial +1, but include coordination between various domains and a number of operations that should perhaps be performed atomically etc… async setters are a footgun that we’d rather avoid IMHO.
It’s the same reasons why not every actor has a func run(whatever: (isolated Self) -> T) async -> T on it, because actors (and OOP!), are a way to organize your code/logic, and not just bob.run { tons of code here } solve everything without actually centralizing logic. If all your actors have is boring “setX” methods… maybe they’re not actually containing any logic that’s important to isolate the state/logic with — to me that’s a smell to act on in the code which ends up having to write this, and not something to resolve by “just” allowing the property setters on actors.
At the other hand, I am curious if perhaps this is somehow showing up here specifically because “so much of stuff is on main actor” AND “a lot of existing libraries require setting properties”. I would definitely welcome more real world examples of the problem showing up. The 3-10 line snippets we have so far in the thread IMHO (personal opinion) are not really justifying exposing the huge footgun to avoid a few lines of code that should often make you step back and rethink if you’re doing what you should be doing.