Hi Norbert,

On Sat, Jan 6, 2018 at 4:32 AM, Norbert Hartl <norbert@hartl.name> wrote:
 
Btw. why is the name NoModificationError? Isn’t the purpose of an Error that it is not resumable? And is NoModificationError very likely to be resumed? Like in #retryModification?

At least for me, errors are orthogonal to reusability.  In fact, that so many errors are not resumable is extremely annoying.  Take the example of reading a directory.  If one doesn't have the permissions to read a directory then attempting to do so is definitely an error.  But if one is trying to write a find-like utility that searches a directory hierarchy then one definitely wants to resume from such an error by answering empty contents.  Otherwise one's search terminates at the first unreadable directory.  So very much,reusability is about an operation's results and continuation, not about it being an error or a warning.

I don't think that NoModificationErrora are very likely to be resumed.  It depends on context.  If one were to try and modify a literal then one would not expect that error to be resumed.  If one is using a, object-to-database mapping scheme then yes, one would expect it to be resumed.  But it depends on what the application is doing, and so I don't think one can say anything about likelihood.

The name is NoModificationError since that's exactly what it is.  The per-object read-only bit stipulates that the object is not modifiable and any attempt to modify its state (which includes what its class is) causes an error.  It's not a NoModificationWarning.  It's a hard error. And in the case of a literal (or any other object we might want one not to be able to modify inadvertently such as a method) we would not expect any kind of resumption.

I hope this is clearer :-)


Norbert

Am 05.01.2018 um 14:34 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

Hi Clément,

    is it too late to take a look at the VisualWorks code and use the same class names and selectors they use?  IIRC it is NoMidificationError.  It may make e.g. Gemstone's job easier if there is some consistency.

_,,,^..^,,,_ (phone)

On Jan 5, 2018, at 5:22 AM, Clément Bera <bera.clement@gmail.com> wrote:

Hi,

No this is not a bug.

This needs to be handled in the primitive failure code in the image, the method should be something like that :

Object>>instVarAt: index put: anObject
<primitive: 174 error: ec>
        self isReadOnlyObject ifTrue: [(ModificationForbidden for: self atInstVar: index with: anObject) signal]
self primitiveFailed

All primitive fall-back code triggering object mutation should be rewritten this way, especially primitives such as #at:put:, #instVarAt:put:, etc.

Cheers

On Fri, Jan 5, 2018 at 1:42 PM, Norbert Hartl <norbert@hartl.name> wrote:
 
If I do 

(#foo -> #bar)
beReadOnlyObject;
value: #baz

it throws

ModificationForbidden:  #foo->#bar is read-only, hence its field 2 cannot be modified with #baz

 which is as expected. But if I do

(#foo -> #bar)
beReadOnlyObject;
instVarNamed: #value put: #baz

I get

PrimitiveFailed: primitive #instVarAt:put: in Association failed

I think this a bug, no?

Norbert




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq





--
_,,,^..^,,,_
best, Eliot