<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Marcel,<br><br><div dir="ltr"><blockquote type="cite"><br>On Sep 3, 2020, at 6:15 AM, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi --<div><br></div><div>#headingAndAutoselectForLiteral:do: is a private helper function to disguise a rather constant value, which is a prefix for a tool's label. It should not be used outside SystemNavigation. That would make things even worse.</div><div><br></div><div>The basic issue here is that there is no specific object for the concerns "user" or "sender". So, it is tediously derived or forwarded in a functional style.</div><div><br></div><div>We should find a way to get rid of <span style="font-size: 10pt">#headingAndAutoselectForLiteral:do:. That very name indicates that there is something wrong with the overall invocation of SystemNavigation's public protocol.</span></div></div></div></blockquote><div><br></div>+1.  Making a SystemNavigation stateful so that it can be assigned something for auto select would be great.  It could also take a pattern not just a string, and hence deal with multi keyword messages better.<div><br></div><div>If we separate the search and presentation functions there are several benefits too:</div><div><br></div><div>- we can get a calculus for search, so that we can have and and or. So something like search for all calls on methods that refer to selector a and selector b in class hierarchy c are easily expressed as the and of three elemental searches, fir selector a, for selector b, for class hierarchy c</div><div><br></div><div>- we can get rid of the duplication in the allFoo and browseAllFoo protocols, keeping the search and just sending browse to the result.</div><div><br></div><div>- we can derive results in the forms we’d like, so a “navigation” could answer methods, classes, packages, method references, etc</div><div><br></div><div>As a suggested implementation Object>>smalltalk or Object>>navigation answers a new SystemSearch instance; SystemSearch instances understand basic queries (allCallsOn:, allImplementorsOf: etc), and an and: and or: protocol that take either another SystemSearch or a message, and answer or update the receiver.  Then at any time one can send autoSelect: to the SystemSearch, and browse to see its results.</div><div><br></div><div>BTW, a concise way of creating a message might be cool; Message selector: #allCallsOn: argument: 123 is fine but a little verbose and tedious to type.  #allCallsOn: << { 123 } might be nice, or a little too cryptic.  I don’t know.</div><div><br></div><div>Btw, Andreas hated and I hate typing systemNavigation; so long.  I implement sn in Object as an abbreviation.  Hence my suggestion of smalltalk or navigator above.  search would be even better:</div><div><br></div><div>     (self search</div><div>          allCallsOn: #systemNavigation) “sets systemNavigation as the default auto select string”</div><div>          and: #inPackage: << { #Tools };</div><div>          browse</div><div><br></div><div>is much more flexible than </div><div>    self sysyemNavigation browseAllCallsOn: #systemNavigation loxalToPackage: #Tools</div><div><br></div><div>Or have and: be the default combinatorial so one can cascade ands:</div><div><div><br></div><div>     self search</div><div>          allCallsOn: #systemNavigation;</div><div>          inPackage: #Tools;</div><div>          browse</div></div><div><br></div><div>I like this last one.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000"><div><br></div><div>Best,</div><div>Marcel</div><div><br></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;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 03.09.2020 15:02:06 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">


<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif">
<p>Hi Chris,</p>
<p><br>
</p>
<p>thanks for your feedback!</p>
<div id="x_Signature">
<div id="x_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="x_divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif;font-size: ;margin: 0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</span></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">> <span style="font-size: 12pt">For your code contributions in general, please allow methods to have </span><span style="font-size: 12pt">only a single exit as much as possible, as in the attached.</span>
<div><br>
</div>
<div>I think this is very much a question of favor - personally, I prefer guard clauses over the functional style unless both code paths have the same relevance for the whole method. In my opinion, an empty message list is clearly a secondary edge case only.
 :-)</div>
<div><br>
</div>
<div>> <span style="font-size: 12pt">I like the multilingual change, but the purpose of using </span><span style="font-size: 12pt">#headingAndAutoselectForLiteral:do: here wasn't obvious to me.</span>
<div><br>
</div>
<div>Yes, this is not really an intuitive message name ... What do you think about calling it #readLiteral:withHeadingAndStringDo: instead (plus making it public)?</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</div>
</div>
</div>
<div><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Chris Muller <asqueaker@gmail.com><br>
<b>Gesendet:</b> Mittwoch, 2. September 2020 23:59:46<br>
<b>An:</b> squeak dev; Thiede, Christoph<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Tools-ct.986.mcz</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div class="PlainText">Hi Christoph,<br>
<br>
For your code contributions in general, please allow methods to have<br>
only a single exit as much as possible, as in the attached.<br>
<br>
I like the multilingual change, but the purpose of using<br>
#headingAndAutoselectForLiteral:do: here wasn't obvious to me.<br>
<br>
Best,<br>
  Chris<br>
<br>
On Wed, Sep 2, 2020 at 9:56 AM <commits@source.squeak.org> wrote:<br>
><br>
> Christoph Thiede uploaded a new version of Tools to project The Inbox:<br>
> <a href="http://source.squeak.org/inbox/Tools-ct.986.mcz">http://source.squeak.org/inbox/Tools-ct.986.mcz</a><br>
><br>
> ==================== Summary ====================<br>
><br>
> Name: Tools-ct.986<br>
> Author: ct<br>
> Time: 2 September 2020, 4:55:38.538083 pm<br>
> UUID: b4cdf611-f04b-0b40-8f61-34429f414cca<br>
> Ancestors: Tools-ct.985<br>
><br>
> Fixes MNU when adding senders of a non-string literal to a message trace (at the end, FindText was set to a number or something similar). Improves multilingual support.<br>
><br>
> =============== Diff against Tools-ct.985 ===============<br>
><br>
> Item was changed:<br>
>   ----- Method: MessageTrace>>addParentMethodsSending: (in category 'building') -----<br>
>   addParentMethodsSending: selectorSymbol<br>
><br>
> +       ^ self systemNavigation<br>
> +               headingAndAutoselectForLiteral: selectorSymbol<br>
> +               do: [:label :autoSelect |<br>
> +                       | methodsList |<br>
> +                       methodsList := self systemNavigation allCallsOn: selectorSymbol.<br>
> +                       methodsList ifEmpty: [<br>
> +                               ^ self inform: ('There are no {1}' translated format: {label})].<br>
> +                       self<br>
> -       | methodsList |<br>
> -       (methodsList := self systemNavigation allCallsOn: selectorSymbol) isEmpty<br>
> -               ifTrue:<br>
> -                       [ ^(PopUpMenu labels: ' OK ')<br>
> -                               startUpWithCaption: 'There are no methods that send ', selectorSymbol ]<br>
> -               ifFalse:<br>
> -                       [ self<br>
>                                 addParentMessages: methodsList<br>
> +                               autoSelectString: autoSelect]<br>
> -                               autoSelectString: selectorSymbol ]<br>
>   !<br>
><br>
><br>
</div>
</span></span>
</div></blockquote></div><span></span><br></div></blockquote></div></body></html>