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 <dionisi...@gmail.com>: > > 2017-01-25 15:52 GMT+01:00 Clément Bera <bera.clem...@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? >
