Hi Clément,
On Tue, Jul 18, 2017 at 9:01 AM, Clément Bera bera.clement@gmail.com wrote:
Hi all,
I am not sure that's what you are talking about, as there is no true immutability in the Cog VM but only read-only objects (terminology agreed upon on the VM mailing list after multiple long discussions and I will ignore further discussions on this matter), but in the case of the supported read-only objects, the VM checks if the object is read-only when performing become and *fails* the primitive if so.
Except that we made a mistake and didn't check for a read-only target. Not that that's an issue in this bug because the default becomeForward: in Squeak and Pharo has copyHash true (why I'm not sure yet; seems very dangerous to me :-) ), and Squeak doesn't have read-only literals yet. So the bug in this case was modifying the hash of #normal and hence causing failures to find #normal in MethodDictionaries. So while I'm fixing the VM code, it won't prevent this crash. I've asked Bert for the rationale of making copyHash true by default.
This is done when checking if the oop is a valid become object (hence, I believe in the case of becomeForward, only one object is checked). Among multiple reasons (implementation details, complexity, tricky cases, etc.), it was implemented this way as it is simpler and it is possible to write a work-around that way:
readOnlyObject beWritableObject. readOnlyObject become: anotherWritableObject. readOnlyObject beReadOnlyObject.
However, if at some point someone implements true immutability (i.e. the object cannot be modified once created immutable and cannot be writable again) in the VM, then the work-around does not work and one could consider alternatives.
Best,
On Tue, Jul 18, 2017 at 5:36 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2017-07-18 16:51 GMT+02:00 Bert Freudenberg bert@freudenbergs.de:
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, butit'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 ofimmutable 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. And "mutableObj becomeForward: immutableObj copyHash: false" should be the only allowed become case.
What if I change a class or superclass of an immutable? (think add or remove an instance variable)
Bert -
Bert -