Hi Bert,

On Tue, Jul 18, 2017 at 7:51 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:

On Tue, Jul 18, 2017 at 4:46 PM, Levente Uzonyi <leves@caesar.elte.hu> wrote:
On Tue, 18 Jul 2017, Bert Freudenberg wrote:

I don't know how the VM handles immutability in this case, but it's possible that it wouldn't let #become*: affect immutable objects.

I think that would be fine, you should be able to become an immutable object and vice versa.

On the other hand, I'm sure it would let you change fields of immutable objects via #become*:, but that's not an issue in your case.

This is debatable ... I would rather have the VM raise an error when trying to become a field of an immutable object. Immutable should mean
immutable, no?

#become: would become slow again if we had to find all objects referencing the one we're about to swap. Or, we'd have to make the whole object graph immutable when we make an object immutable. In that case #become: could just fail when the receiver or the argument is immutable.

+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.

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, provided it does't imply that classes can't change).

And "mutableObj becomeForward: immutableObj copyHash: false" should be the only allowed become case.

Agreed.

- Bert -

_,,,^..^,,,_

best, Eliot