Another question Clement.

I found that current method doing something strange:

attemptToAssign: value withIndex: index��
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1.
Processor yield.
"CAN'T REACH"

Could you comment why new process needed here?��

I just check simple version with error and it works:

attemptToAssign: value withIndex: index��
^self error: 'modification failed'.

Also if I will modify #contents: as "^contents:=newValue" then following code is working well:

o := ValueHolder new.
o beReadOnlyObject.
[o contents: #test] on: Error do: [:err | err resumeUnchecked: #done]. "=> #done"

So I not understand the problem described in method comment.

2017-01-25 16:21 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-01-25 15:52 GMT+01:00 Cl��ment Bera <bera.clement@gmail.com>:
Overall, you need to:
- change the code of all numbered primitives mutating objects (such as at:put:) so that when they fail because of a read-only object they call the modification tracker framework.

I think it is for future.

But now behaviour is just inconsistent because making object readonly breaks any app using it silently.��
Also I see that instVarAt:put: will raise error instead of skipping it. So two ways to modify object lead to different behavior. It's not good.

My conclusion: it must be error by default. Something like this:
Object>>#attemptToAssign: value withIndex: index��
�� (ModificationForbidden for: self at: index with: value) signal
It is not fix completely inconsistence with #instVarAt:put: but at least they both will fail.

By the way I was supprized that failed #instVarAt:put: shows "bad receiver" in primitive er variable (<primitive: 174 error: ec>). Is "bad receiver" is always about mutability? And if not then how we will distinguish different cases?