<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>