<body><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><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>
<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>
<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>
</blockquote>
<p>
<div></div>
<br>
<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>
<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>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></body>