<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 7:18 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</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"><div dir="auto">Hi Marcel,<br><br><div dir="ltr"><blockquote type="cite"><br>On Sep 3, 2020, at 6:15 AM, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div id="m_-3518140685576048280gmail-m_-3242974439423089324__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
                                        
                                        
                                            
                                        
                                        
                                        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></blockquote><div><br></div><div>+1, I kinda like that!   Although, some objects already implement #<< , hmm...<br></div><div><br></div><div>For years, I've actually been wanting a convenience constructor for MethodReference.  I _wish_ I could write</div><div><br></div><div>     Integer>>#gcd:</div><div><br></div><div>and get a MethodReference instead of a CompiledMethod, since I can easily send #compiledMethod to a MethodReference if I want that (which, I never do, I only ever want the Reference).  I suppose I could implement CompiledMethod>>#asMethodReference, it'd just be so much nicer if it were the other way...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><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:<br></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></blockquote><div><br></div><div>A great improvement!  Except #search.  We should stay with #systemNavigation.  We developers have autoComplete, etc., we shouldn't poach Object>>#search from the API namespace from users.</div><div><br></div><div>For the ultimate method-selecting power in the universe, MaBehaviorFinder takes the above concept one step further.  Instead of always starting with "all" and filtering, it provides both adding AND removing filters.  So the above example could be:</div><div><br></div><div>       self systemNavigation</div><div>            addCallsOn: #systemNavigation ;         "adding filter"</div><div>            selectPackage: #Tools ;                         "removing filter"</div><div>            browse</div><div><br></div><div>Or, equally:</div><div><br></div><div><div>       self systemNavigation</div><div>            addPackage: #Tools ;                          "adding filter"</div><div>            selectCallsOn: #systemNavigation      "removing filter"</div><div>            browse</div><div><br></div><div>So, various "add" API, ADDS methods to the result, while various "select" API, removes them from the result.  (There's even a third family, "reject" which select the opposite of "select").</div><div><br></div><div>There's quite a few methods, but executing them in succession on a stateful instance, as you've described for SystemNavigation here, is exactly how it works, and it's fabulous!   :-D</div><div><br></div><div>Just in case anyone is interested in taking a peek at it for inspiration, the following will pop it up:</div><div><br></div><div>      Installer new merge: #maInstaller.<br>      (Smalltalk classNamed: #MaInstaller) new merge: #base.<br></div><div>      (Smalltalk classNamed: #MaBehaviorFinder) browse</div><div><br></div><div> - Chris</div><div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div><blockquote type="cite"><div dir="ltr"><div id="m_-3518140685576048280gmail-m_-3242974439423089324__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><br></div><div>Best,</div><div>Marcel</div><div><br></div><div></div>
                                        
                                        <blockquote 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:rgb(170,170,170);margin-top:10px">Am 03.09.2020 15:02:06 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">


<div dir="ltr">
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>Hi Chris,</p>
<p><br>
</p>
<p>thanks for your feedback!</p>
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_Signature">
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_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">
<div>
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_Item.MessagePartBody">
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_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="m_-3518140685576048280gmail-m_-3242974439423089324x_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 id="m_-3518140685576048280gmail-m_-3242974439423089324x_Item.MessagePartBody"><br>
</div>
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_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:rgb(128,128,128)"></span></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-3518140685576048280gmail-m_-3242974439423089324x_divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b>Von:</b> Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>><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>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 <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>> 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" target="_blank">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></div><br>
</blockquote></div></div>