Hi Clément,

On Tue, Jul 18, 2017 at 9:01 AM, Clément Bera <bera.clement at 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 at gmail.com> wrote:
>
>>
>>
>> 2017-07-18 16:51 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:
>>
>>> On Tue, Jul 18, 2017 at 4:46 PM, Levente Uzonyi <leves at 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. 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 -​
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170718/c3f5d255/attachment.html>