<div dir="ltr"><div dir="ltr">On Sat, Apr 25, 2020 at 3:06 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>>:<br>
>><br>
>> 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<br>
><br>
><br>
> 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...<br>
><br>
<br>
Hmm for this particular case I don't see the issue. Modification<br>
through an inspector will create references to other objects, so to<br>
run into ModificationForbidden here, you would have to modify a<br>
composite literal object, which could only be an Array if I am not<br>
mistaken. </blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The elements of literal arrays are literals themselves (not<br>
in the CompiledMethod-sense, but they are all immutable now, right?<br>
think of nested arrays). </blockquote><div><br></div><div>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..</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So when you press Cmd+s, you will immediately<br>
get the exception, before anything changes in the object. So the<br>
database would not be affected by the error or the modification<br>
attempt, right?<br>
<br>
Or it would proceed immediately because it was registered so in the<br>
object-specific handler supplied via the methods in Marcel's<br>
changeset. Then things get modified and so they would be in the<br>
database. Do you mean the exception could arise again in the database<br>
code?<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div> - Chris</div><div> </div></div></div>