<div dir="ltr"><div dir="ltr">Hi Christoph,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 11, 2020 at 7:32 AM Thiede, Christoph <<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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<div id="gmail-m_920772415718823784divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<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 size="3449" id="gmail-m_920772415718823784img99353" style="max-width: 99.9%;" src="cid:1719ae62654f456b1e51"> <img size="4270" id="gmail-m_920772415718823784img899934" style="max-width: 99.9%;" src="cid:1719ae62654f456b1e52"><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></div></div></div></div></blockquote><div><br></div><div>There are many use cases for the same exception, just as there are many use cases for bounds violations or divide by zero, or, or, .... The point is that at the point where the exception is raised neither the VM nor the code immediately above it knows what the use case is, and the exception is raised precisely to find out how the exception should be handled, which means that sears hing for the exception/.handling the exception is about discovering what the particular use case *is*. Sio no, one can't magically intuit what the high level use case is at the point of failure. That's *why* we have exception systems.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div id="gmail-m_920772415718823784divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><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">
<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" target="_blank">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="gmail-m_920772415718823784Signature">
<div id="gmail-m_920772415718823784divtagdefaultwrapper" 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">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_920772415718823784divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>><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" rel="noreferrer" target="_blank">asqueaker@gmail.com</a>> a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);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-width:1px;border-left-style:solid;border-left-color: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>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>