On Tue, Jul 18, 2017 at 10:10 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Tue, Jul 18, 2017 at 7:51 AM, Bert Freudenberg bert@freudenbergs.de wrote:
+1 for making the whole object graph be immutable.
This really doesn't make sense as it prevents any kind of change at all, e.g. to the class hierarchy, and as Nicolas points out, prevents updating objects if their class definitions are modified.
When we added "immutability" to VisualWorks (actually read-only objects) we held off, and made only literals immutable. I'd like to see us make CompiledMethods immutable too, but this wold introduce complications in condensing changes/sources, adding/deleting breakpoints, etc. One can provide an exception handler or a beMutableWhile: facility to make it easy to temporarily make read-only objects writable.
Right.
Or are you meaning that when an object is made immutable all its sub-state
is made immutable too? (An idea I have no problems with,
Yes, that. Which means that immediates and nil/true/false should become immutable too. In fact, isn't any stateless object already immutable?
provided it does't imply that classes can't change).
The class should not be made immutable, agreed, but you shouldn't be able change the shape of instances, me thinks.
- Bert -