<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Sep 30, 2020, at 3:48 AM, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Alright, anyone having any new opinion about this? Let's make a decision! :-)</p></div></div></blockquote><div><br></div><div><br></div>I don’t see how it can be other than an error. If one attempts to modify a literal that is an error. If one attempts to modify a read-only object then that is an error, unless some smart system is overloading read-only-ness to implement a read barrier.<div><br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Best,</p>
<p>Christoph</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Chris Muller <asqueaker@gmail.com><br>
<b>Gesendet:</b> Donnerstag, 24. September 2020 21:33:27<br>
<b>An:</b> The general-purpose Squeak developers list; Thiede, Christoph<br>
<b>Betreff:</b> Re: [squeak-dev] Why is ModificationForbidden not an Error?</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Christoph,
<div><br>
</div>
<div>Magma does not depend on ModificationForbidden. My participation in this discussion was merely for my own learning, to try to overcome my skepticism about ModificationForbidden. Changing its superclass shouldn't affect Magma at all. Whether Magma will
be able to make use of it is still up in the air. Please feel free to integrate what you and the other folks interested in this decide is best.</div>
<div><br>
</div>
<div>Thanks!</div>
<div> Chris</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 4:09 AM Christoph Thiede <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de">christoph.thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Chris, hi all,<br>
<br>
after months of stagnation, I'd like to bring up this open discussion again.<br>
IMO the current situation in the Trunk is still buggy and the last thing we<br>
want developers to have to care about. For example, I recently crashed a<br>
number of smalltalkCI builds again because some method raised a<br>
ModificationForbidden, which the test runner, obviously, was not prepared<br>
for ...<br></blockquote></div></div></div></blockquote><div><br></div>This makes no sense to me. Test runners collect tests that error just as they collect tests that assert fail. Why would a ModificationForbidden Another be considered an error?</div><br><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><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">
From what I can see, the only problem with my proposal that resists still in<br>
the inbox, Kernel-ct.1321, is related to Chris' Magma implementation. I want<br>
to respect this use case (and actually, learning a bit more about Magma is<br>
already on my long, long list of nice-to-do stuff), but I have to agree with<br>
other people saying that ModificationForbidden is a very low-level error and<br>
should not need any special treatment. For this reason, I also think that<br>
Marcel's changeset is a bit over-engineered for the Trunk, given the<br>
particular fact that we do not have plans for any user of ManagedObjects in<br>
the Trunk.<br>
<br>
Chris, did anything happen on your end regarding the handling of<br>
ModificationForbidden in Magma? Iirc you mentioned recently that you have<br>
reached some kind of feature completeness in your project. Can't we just<br>
merge Kernel-ct.1321 for now and resolve this discussion until some new use<br>
case arises? For Magma as an external project (still without being familiar<br>
at all with its design), I don't understand what would be wrong with<br>
handling such exceptions using #on:do:, this would totally suffice to<br>
circumvent the #defaultAction implementation. If you do not have the<br>
possibility to install an exception handler or a ToolSet, you could still<br>
place an extension override method in ModificationForbidden and<br>
(conditionally) inject your custom handling logic there.<br>
<br>
What do you think? I would like to finally get ahead with this issue! :-)<br></blockquote></div></div></div></blockquote><div><br></div>I don’t want yo build something that is incompatible with gemstone. Currently we don’t have their attention; Ogaro had thrrr attention. So we have to do the work of ensuring that ModificationForbidden supports the Gemstone use case; it’s a very very important one. on:do: is completely inadequate for this. One needs a system wide exception handler where any ModificationForbidden is routed through a manager that is able to identify that the object in question is in fact being mapped to a database (or a remote system, or a breakout ring system etc). But on:do: handlers are for specific flows of control (currently within a single thread) and cannot serve as system wide handlers.</div><div><br></div><div>Here’s a simplified use case. The programmer wants to be able to trace wherever in the system an object is modified. It may occur in arbitrary processes, not just in the current flow of control. To do this efficiently the programmer uses ModificationForbidden to catch a modification, log it, make the object readable, effect the modification, make the object read-only again and proceed. This *cannot* be done with an on:do: handler.</div><div><br><blockquote type="cite"><div dir="ltr"><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">
<br>
Best,<br>
Christoph<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html" rel="noreferrer" target="_blank">
http://forum.world.st/Squeak-Dev-f45488.html</a><br>
<br>
</blockquote>
</div>
</div>
<span></span><br></div></blockquote></div></body></html>