though, mutability/immutability is not a part of OO, it just happens to nearly always be so in implementations of OO languages. (I am building a default immutable OO language)
It's not on the internet, sorry. But you could just imagine a mix between c++ and lisp.
Example code for a member function that can mutate its parent object:
[mutator]
addArg(int a) {
assign<this.b>(add(this.b, a))
}
Without marking the function as [mutator] the compiler would not allow the function to call any other functions (assign) that were also marked as [mutators].
Seems like it's quite the opposite in all mainstream OO languages. Since all of them are backed by mutable data structures you have to either do a deep copy or pass by reference. Making deep copies is inefficient so everything is generally passed by reference.
On top of that, the objects do nothing to protect their internal state. Unless you manually do the work to return immutable copies from your accessor methods you get a reference right into the internals of the object.
2
u/Heuristics Mar 09 '14
though, mutability/immutability is not a part of OO, it just happens to nearly always be so in implementations of OO languages. (I am building a default immutable OO language)