[Vm-dev] Bug in #instVarAt:put: for read-only objects

Eliot Miranda eliot.miranda at gmail.com
Sat Jan 6 18:24:33 UTC 2018


Hi Norbert,

On Sat, Jan 6, 2018 at 4:32 AM, Norbert Hartl <norbert at 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 at 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 at 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 at 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
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180106/7cb5b5cf/attachment.html>


More information about the Vm-dev mailing list