<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Marcel,</p>
<p><br>
</p>
<p>> <span style="font-size: 12pt;">Every change to the interface of CompiledCode (etc.) can make all existing "method objects" incompatible.</span></p>
<div><br>
</div>
<div>This was my motivation for Approach C. If I do not miss anything, this would free us from defining the same interface twice.</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</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 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> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Montag, 24. Februar 2020 14:11:27<br>
<b>An:</b> John Pfersich via Squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] [BUG] Objects as methods break method search</font>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Christoph, hi all!
<div><br>
</div>
<div>The overall tool support for object-as-method feels kind of poor. We might want to think about that on a more general level. Every change to the interface of CompiledCode (etc.) can make all existing "method objects" incompatible.</div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel</div>
<div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 24.02.2020 13:42:58 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<div id="divtagdefaultwrapper" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif" dir="ltr">
<p><b>Steps to reproduce:</b></p>
<p>Debug TestObjectsAsMethods >> #<span>testAddNumbers, for example. Keep the debugger open.</span></p>
<p><span>Search for senders of any literal in your image, for example, "senders of #foo".</span></p>
<p><span><br>
</span></p>
<p><span><b>Expected behavior:</b></span></p>
<p><span>A MessageTrace with the calling methods opens as usual.</span></p>
<p><span><br>
</span></p>
<p><span><b>Actual behavior:</b></span></p>
<p><span>In SystemNavigation >> #<span>allCallsOn:fromBehaviors:sorted:, an exception is raised:</span></span></p>
<p><span>MessageNotUnderstood: ObjectsAsMethodsExample>>hasLiteral:scanForSpecial:.<b></b><br>
</span></p>
<p><span><br>
</span></p>
<p><span><b>Considerations:</b></span></p>
<p>There are further bugs, for example, browse implementors of #foo, which will give you an MNU for <span>AbstractObjectsAsMethod>>isDeprecated.</span></p>
<p>I see three possible solution approaches:</p>
<p><br>
</p>
<p><b>Approach A:</b> Define an abstract superclass of all "objects as methods" classes, for example in <span>AbstractObjectsAsMethod. Add an implementation of #<span>hasLiteral:scanForSpecial: there, it might be sufficient to return false.</span></span></p>
<p><span><span><b>Pro:</b> We can assure each value in a method dictionary actually understands a minimum protocol and do not need to add safety checks at other places such as SystemNavigation.</span></span></p>
<p><span><span><b>Con:</b> We increase the complexity of implementing an object as method. By requiring a certain superclass, it is not possible for an existing class to accept the OaM responsibility.</span></span></p>
<p><span><b>Con: </b>The number of methods to implement in this superclass might be large and unclear.</span></p>
<p><span><span><br>
</span></span></p>
<p><span><span><b>Approach B:</b> In <span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;font-size: 16px">SystemNavigation >> #</span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;font-size: 16px">allCallsOn:fromBehaviors:sorted:,
 check that method responds to #hasLiteral:scanForSpecial: before sending the message, or catch any DNUs via #ifError: or so. In CodeHolder >> #<span>formattedLabel:forSelector:inClass:, we would need to wrap the call to #isDeprecated the same way.</span></span></span></span></p>
<p><span><span><span 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>Con:</b> There is possibly a very large number of
 clients of method dictionaries. It will be a mess to secure them all.</span></span></span></p>
<p><span><span><span 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>
</span></span></span></p>
<p><span><span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;font-size: 16px">Note also how <span>WrappedBreakpoint and TestCoverage
 are implemented. They keep a reference to the actual CompiledMethod they replace and forward all messages not understood to this method. There is duplication among these two classes, maybe we should refactor this as well.</span></span></span></span></p>
<p><span><span><span 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>However, the forwarding approach cannot work if
 there is no wrapped method available.</span></span></span></span></p>
<p><span><span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;font-size: 16px">So
<b>Approach C</b> would be: </span></span></span>Should we maybe provide some kind of "null method object" we could forward all unknown messages to? Each OaM implementor that is not a wrapper then would need to implement the following method:</p>
<p><br>
</p>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<p>doesNotUnderstand: aMessage</p>
</blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<p>^ aMessage sendTo: CompiledMethod nullMethod</p>
</blockquote>
</blockquote>
<p></p>
<p><span><span><span 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><br>
</span></span></span></span></p>
<p><b>Pro:</b> Very easy to implement for both users of method dictionaries and implementors of OaM.</p>
<p><b>Con:</b> I<span>t is not possible for an existing class that already forwards messages via #doesNotUnderstand: to accept the OaM responsibility. But this appears rather a hypothetic problem to me, as you could always decompose this responsibility ...</span></p>
<p><span><span><span 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><br>
</span></span></span></span></p>
<p><span><span><span 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><span style="color: rgb(117, 123, 128);font-size: 10pt">(For
 illustration, </span><span style="color: rgb(117, 123, 128);font-size: 10pt">t</span><span style="color: rgb(117, 123, 128);font-size: 10pt">he probably cheapest fix of the concrete bugs mentioned above might be this:</span></span></span></span></span></p>
<p><br>
</p>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<p></p>
<div><span style="color: rgb(117, 123, 128);font-size: 10pt">AbstractObjectsAsMethod >>
</span><span style="color: rgb(117, 123, 128);font-size: 10pt">doesNotUnderstand: aMessage</span></div>
<p></p>
<p></p>
<div><span style="white-space: pre;color: rgb(117, 123, 128);font-size: 10pt"></span><span style="color: rgb(117, 123, 128);font-size: 10pt">^ aMessage sendTo: thisContext method</span></div>
<p></p>
</blockquote>
<p></p>
<div></div>
<br>
<p></p>
<p><span style="color: rgb(117, 123, 128);font-size: 10pt">But this is the drawback of such a workaround:</span></p>
<p><br>
</p>
<p></p>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<p><img size="31396" contenttype="image/png" id="img786456" style="max-width: 99.9%; user-select: none;" contextid="img16968" tabindex="0" src="cid:e740fd3a-62ea-442c-8eff-a3517c7d92a0"><!-- </img> --><span style="color: rgb(117, 123, 128);font-size: 10pt">)</span></p>
</blockquote>
<br>
<p></p>
<p>So, which way would you go? To me, approach C sounds most useful, as we could actually provide a tweaked instance of CompiledMethod instead of reimplementing the protocol in another class (and having to maintain it).</p>
<p>Do we already have any constructor that could work as a method null object? Something like "<span>Compiler new compiledMethodFor: '' in: nil to: nil notifying: nil ifFail: nil"? But this one has also two literals.</span></p>
<p><br>
</p>
<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><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>