On Wed, Jan 25, 2017 at 4:42 PM, Denis Kudriashov <dionisi...@gmail.com> wrote:
> 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. > Hi Denis, I will look into this case tomorrow, it looks like a bug. Thanks for reporting. For the Process hack, it's because the call-back was designed to return no value. It may look like it works when returning a value but you will have uncommon crashes. > 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? >> > >
