<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" 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;" dir="ltr">
<p></p>
<div><span style="font-size: 12pt;">Just another thought: I see some confusion around the Proceed button in the debugger, and I felt the same confusion sometimes ago. Please forgive me for the sacrilege, but should we maybe question its general existence?</span></div>
<div><span style="font-size: 12pt;"><br>
</span></div>
<div><span style="font-size: 12pt;">Depending on the domain, it actually performs a mix of #retry (made possible by the quite </span><a href="http://forum.world.st/I-broke-the-debugger-td5110752.html#a5112307#:~:text=recursively" class="OWAAutoLink" style="font-size: 12pt;">confusing</a><span style="font-size: 12pt;"> recursive
implementation of Object >> #at:, Object >> #doesNotUnderstand: and others, I did not yet found any other motivation than the Proceed button to use recursion here) and ignore (#resumeUnchecked:, especially useful for UnhandledWarnings and Halts). Would it
be a reasonable goal to eliminate this button in the pre-debugger window and replace it with two buttons, Restart and Ignore? We could hide even hide the restart button if not appropriate (i.e., the exception is not an error).</span><br>
</div>
<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 id="divtagdefaultwrapper" 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;" dir="ltr">
<br>
</div>
What do you think?</div>
<div id="divtagdefaultwrapper" 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;" dir="ltr">
And it would be great if anyone here could explain why Object >> #at: & Co. are recursive! :-)</div>
<div id="divtagdefaultwrapper" 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;" dir="ltr">
<br>
</div>
<div id="divtagdefaultwrapper" 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;" dir="ltr">
Best,</div>
<div id="divtagdefaultwrapper" 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;" dir="ltr">
Christoph<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Thiede, Christoph<br>
<b>Gesendet:</b> Samstag, 11. April 2020 16:32 Uhr<br>
<b>An:</b> Chris Muller; The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Why is ModificationForbidden not an Error?</font>
<div> </div>
</div>
<div>
<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;">
<p>Hi all! Thank you very much for having this interesting discussion :-)</p>
<p><br>
</p>
<p>@Chris:</p>
<p>> > <span style="font-size:12pt">-1. :-) Warnings are Notifications,</span></p>
<div>> As are Errors. Right?</div>
<div><br>
</div>
<div>Nope, sorry ;-)</div>
<div><img naturalheight="58" naturalwidth="100" size="3449" id="img99353" tabindex="0" style="max-width: 99.9%; user-select: none;" src="cid:1a371365-7210-4ea3-a6da-6dfbd89c6b54"> <img naturalheight="58" naturalwidth="118" size="4270" id="img899934" tabindex="0" style="max-width: 99.9%; user-select: none;" src="cid:1000a733-fc69-4ba3-bae8-c3cf25021584"><br>
</div>
<div><br>
</div>
<div>> <span>The two main use cases of ModificationForbidden present opposite perspectives onto it. For "protection from accidentally modifying a literal in a CompiledMethod", I understand the inclination to make it an Error. However, for the context of db
handling, [#markDirty + #resume] is normal processing, not an "error", and not even exceptional, either, so perhaps this is just a semantic irritation sensitivity on my part.. sorry. </span></div>
<div><br>
</div>
<div><span style="font-size:12pt">> </span><span style="font-size:12pt">But if they want to use ModificationForbidden for a Write Barrier, they'll probably want to extricate it from Error in the handler:</span><br>
</div>
<div>
<div>> </div>
<div>> [ myDbApp doStuff ]</div>
<div>> on: ModificationForbidden</div>
<div>> do:</div>
<div>> [ : forbidden |</div>
<div>> forbidden object beWritableObject.</div>
<div>> forbidden resumptionValue: forbidden retryModificationNoResume.</div>
<div>> forbidden resume: forbidden resumptionValue ]</div>
<div>> on: Error</div>
<div>> do: [ : err | myDbApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
This clarification was very helpful for me. I was not aware of your second use case before.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
In my opinion, we are talking about two completely different use cases for the same exception.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<b>Literal protection</b> is a low-level error, comparable to out-of-bounds things and primitive failures. You almost never do want to ignore or fix them.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<b>Write barriers</b> for #markDirty, on the other hand, sound like a domain-specific topic to me that should neither raise an error, nor eventually signal an UnhandledError, but be resumed automatically (unless handled differently) by a #defaultAction that
removes the barrier (and additional handlers could, if desired, turn on some cache or so).</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
I have never dealt with Magma or any other DB framework for Smalltalk, but why do you (or would you) use these VM-based mechanisms for a high-level feature? Without knowing any details about your application, personally I would probably design an own exception
(DirtyModification?) for that purpose. This would allow you to clearly distinguish between low-level errors ("whoops, I just made an attempt to change a read-only code literal") and higher-level exceptions (DirtyModification). If we would follow my <a href="http://forum.world.st/The-Trunk-Kernel-eem-1317-mcz-td5113273.html#a5113433" class="OWAAutoLink">proposal</a> to
raise ModificationForbidden from Object instead of Context, you could also consider to override #modificationForbiddenFor:at:put: in your database objects to raise DirtyModification instead of ModificationForbidden (in the same way as some classes override
#error or #primitiveError).</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<br>
</div>
However, focusing again on the literal protection aspect, I still don't see when the current default #resume behavior of ModificationForbidden would be ever helpful. MF >> #resume calls Exception >> #resume: which does nothing more than to return resumptionValue!
When do we actually need this resumptionValue?</div>
</div>
<div><span style="font-size:12pt">Why can't we design MF like the following:</span><br>
</div>
<div><br>
</div>
<div>#resume - not possible, will signal IllegalResumeAttempt</div>
<div>#retryModification - retries the modification and returns nothing special</div>
<div>#forceModification: - makes the object to modify writable, retries the modification and, optionally, makes the object read-only again</div>
<div><br>
</div>
<div><span style="font-size:12pt">> </span><span style="font-size:12pt">If we don't want to break things (that are somehow </span><span style="font-size:12pt">wrong according to contemporary notion), we could make it a Warning in </span><span style="font-size:12pt">the
Squeak 5.x release stream and turn it into an error with Squeak </span><span style="font-size:12pt">6.0. That is: make it an Error today in Trunk, but if we would create </span><span style="font-size:12pt">a 5.4 release, we would have to remember changing
it back... :-/</span><br>
</div>
</div>
<div><span style="font-size:12pt"></span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">IIRC ModificationForbidden was introduced in 6.0alpha the first time?</span></div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<div><span style="font-size:12pt">
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
<span style="font-size:12pt"></span></div>
</span></div>
<p></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><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com><br>
<b>Gesendet:</b> Samstag, 11. April 2020 11:16:00<br>
<b>An:</b> Chris Muller; The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Why is ModificationForbidden not an Error?</font>
<div> </div>
</div>
<div>
<div dir="auto">
<div dir="auto"></div>
In this case we might want specialized subclasses...
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">Le sam. 11 avr. 2020 à 03:45, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank" rel="noreferrer">asqueaker@gmail.com</a>> a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr">I think so, because if you try to use it for something else, it'll get entangled with your application's standard error handling. Regular apps have error handling like:
<div>
<div><br>
</div>
<div> [ myApp doStuff ] on: Error do: [ : err | myApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>and so for the use-case, <i>Protect CompiledMethod Literals from Accidental Modification</i>, inheriting from Error will allow the best backward compatibility with existing handlers.</div>
<div><br>
</div>
<div>But if they want to use ModificationForbidden for a <i>Write Barrier</i>, they'll probably want to extricate it from Error in the handler:</div>
<div><br>
</div>
<div> [ myDbApp doStuff ]</div>
<div> on: ModificationForbidden</div>
<div> do:</div>
<div> [ : forbidden |</div>
<div> forbidden object beWritableObject.</div>
<div> forbidden resumptionValue: forbidden retryModificationNoResume.</div>
<div> forbidden resume: forbidden resumptionValue ]</div>
<div> on: Error</div>
<div> do: [ : err | myDbApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>But now that I'm handling ModificationForbidden separately, what if I want <i>Protect CompiledMethod Literals from Accidental Modification</i>, too? I'm no longer handling correctly for that, because the handler has to assume they're signaled in the context
of the DB use case and not the Protection use case.</div>
</div>
<div><br>
</div>
<div> - Chris</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 12:06 PM tim Rowledge <<a href="mailto:tim@rowledge.org" rel="noreferrer noreferrer" target="_blank">tim@rowledge.org</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">
<br>
<br>
> On 2020-04-09, at 6:55 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" rel="noreferrer noreferrer" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> <br>
> The two main use cases of ModificationForbidden present opposite perspectives onto it.<br>
<br>
In that case perhaps we actually need two different signals? <br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" rel="noreferrer noreferrer" target="_blank">
tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer noreferrer noreferrer" target="_blank">
http://www.rowledge.org/tim</a><br>
Useful random insult:- Has an inferiority complex, but not a very good one.<br>
<br>
<br>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>