[squeak-dev] The Inbox: Tools-ct.986.mczEliot Miranda eliot.miranda at gmail.comTue Sep 29 12:17:59 UTC 2020
Hi Marcel, > > On Sep 3, 2020, at 6:15 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote: > > > Hi -- > > #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. > > 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. > > We should find a way to get rid of #headingAndAutoselectForLiteral:do:. That very name indicates that there is something wrong with the overall invocation of SystemNavigation's public protocol. +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. If we separate the search and presentation functions there are several benefits too: - 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 - we can get rid of the duplication in the allFoo and browseAllFoo protocols, keeping the search and just sending browse to the result. - we can derive results in the forms we’d like, so a “navigation” could answer methods, classes, packages, method references, etc 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. 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. 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: (self search allCallsOn: #systemNavigation) “sets systemNavigation as the default auto select string” and: #inPackage: << { #Tools }; browse is much more flexible than self sysyemNavigation browseAllCallsOn: #systemNavigation loxalToPackage: #Tools Or have and: be the default combinatorial so one can cascade ands: self search allCallsOn: #systemNavigation; inPackage: #Tools; browse I like this last one. > > Best, > Marcel > >> Am 03.09.2020 15:02:06 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>: >> >> Hi Chris, >> >> >> >> thanks for your feedback! >> >> >> > For your code contributions in general, please allow methods to have only a single exit as much as possible, as in the attached. >> >> 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. :-) >> >> > I like the multilingual change, but the purpose of using #headingAndAutoselectForLiteral:do: here wasn't obvious to me. >> >> Yes, this is not really an intuitive message name ... What do you think about calling it #readLiteral:withHeadingAndStringDo: instead (plus making it public)? >> >> Best, >> Christoph >> Von: Chris Muller <asqueaker at gmail.com> >> Gesendet: Mittwoch, 2. September 2020 23:59:46 >> An: squeak dev; Thiede, Christoph >> Betreff: Re: [squeak-dev] The Inbox: Tools-ct.986.mcz >> >> Hi Christoph, >> >> For your code contributions in general, please allow methods to have >> only a single exit as much as possible, as in the attached. >> >> I like the multilingual change, but the purpose of using >> #headingAndAutoselectForLiteral:do: here wasn't obvious to me. >> >> Best, >> Chris >> >> On Wed, Sep 2, 2020 at 9:56 AM <commits at source.squeak.org> wrote: >> > >> > Christoph Thiede uploaded a new version of Tools to project The Inbox: >> > http://source.squeak.org/inbox/Tools-ct.986.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: Tools-ct.986 >> > Author: ct >> > Time: 2 September 2020, 4:55:38.538083 pm >> > UUID: b4cdf611-f04b-0b40-8f61-34429f414cca >> > Ancestors: Tools-ct.985 >> > >> > 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. >> > >> > =============== Diff against Tools-ct.985 =============== >> > >> > Item was changed: >> > ----- Method: MessageTrace>>addParentMethodsSending: (in category 'building') ----- >> > addParentMethodsSending: selectorSymbol >> > >> > + ^ self systemNavigation >> > + headingAndAutoselectForLiteral: selectorSymbol >> > + do: [:label :autoSelect | >> > + | methodsList | >> > + methodsList := self systemNavigation allCallsOn: selectorSymbol. >> > + methodsList ifEmpty: [ >> > + ^ self inform: ('There are no {1}' translated format: {label})]. >> > + self >> > - | methodsList | >> > - (methodsList := self systemNavigation allCallsOn: selectorSymbol) isEmpty >> > - ifTrue: >> > - [ ^(PopUpMenu labels: ' OK ') >> > - startUpWithCaption: 'There are no methods that send ', selectorSymbol ] >> > - ifFalse: >> > - [ self >> > addParentMessages: methodsList >> > + autoSelectString: autoSelect] >> > - autoSelectString: selectorSymbol ] >> > ! >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200929/b2b6f8c4/attachment.html>
More information about the Squeak-dev mailing list |