[squeak-dev] Why is ModificationForbidden not an Error?

Chris Muller asqueaker at gmail.com
Sat Apr 25 17:57:33 UTC 2020


On Sat, Apr 25, 2020 at 3:06 AM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <
> asqueaker at gmail.com>:
> >>
> >> The fact that there is a helpful default handler for an exception does
> not (should not!) mean you can't catch it and do something more to your
> liking
> >
> >
> > Only if you control the code.  For Magma-like transparency, it must be
> able to operate on oblivious objects which have ZERO knowledge of any
> database or handlers.  Cmd+s in an Inspector should be picked up and saved
> in the next DB commit, unless it's a CM-literal, in which case it should
> error immediately...
> >
>
> Hmm for this particular case I don't see the issue. Modification
> through an inspector will create references to other objects, so to
> run into ModificationForbidden here, you would have to modify a
> composite literal object, which could only be an Array if I am not
> mistaken.


Correct.  And, the Inspector code doesn't know whether its a CM-literal or
just a regular, should-be-updatable Array.  It'll either be registered with
a handler, or it won't.


> The elements of literal arrays are literals themselves (not
> in the CompiledMethod-sense, but they are all immutable now, right?
> think of nested arrays).


No.  From my understanding only the root Array is immutable, the nested
ones aren't.  This isn't related to the issue being raised, just answering
your question..


> So when you press Cmd+s, you will immediately
> get the exception, before anything changes in the object. So the
> database would not be affected by the error or the modification
> attempt, right?
>
> Or it would proceed immediately because it was registered so in the
> object-specific handler supplied via the methods in Marcel's
> changeset. Then things get modified and so they would be in the
> database. Do you mean the exception could arise again in the database
> code?
>

The above is what I'm trying figure out.  My understanding is, if you
registered a handler for the object, it'll run that, otherwise the
defaultAction which is to open a debugger saying ModificationForbidden.

The challenge, at least from the way Magma is implemented, is at the point
where it's time to register an Array with ManagedObjects, there's no way to
know whether it's a CM-literal or not.  But even that is independent of the
fact the read-only bit is still exposed for modification by other
use-cases.  In a coordinated, frozen system like a GemStone business app,
this can be managed.  In a live system that might make use of dynamically
loaded modules, it could be dangerous.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200425/4924a9f4/attachment.html>


More information about the Squeak-dev mailing list