> On 2020-10-19, at 9:39 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
>> + 	messageList := messageList asSortedCollection asOrderedCollection. "Possibly better to do asOrderedCollection sort ?"
> 
> Yes, it's better not to use SortedCollection in this case (as in most cases).
> If messageList does not have to be an OrderedCollection, then
> 
> 	messageList := messageList sorted.
> 
> is the best option.

messageList := messageList asOrderedCollection sort 

seems to work perfectly well and is nicely readable. We do need anOrderedCollection since the tracing adds and removes items in specific indices. I've no idea if the performance would become a practical issue.

In fact, I tried a quick hack to make a list of all the implemented messages to time making a really big message list - but that falls foul of a problem I'm simply not willing to spend any time on right now.

I hacked allUnimplentedCalls to -
allImplementedCalls
	"Answer a collection of each message that is sent by an expression in a method"

	| result  |
	result := OrderedCollection new.
	self allSelectorsAndMethodsDo: [ :behavior :selector :method |
		method selectorsDo: [ :each |			
					result add: (String streamContents: [ :stream |
						stream
							nextPutAll: behavior name;
							space;
							nextPutAll: selector;
							space;
							nextPutAll: 'calls: ';
							nextPutAll: each ])  ] ].
	^result
... to return a list in the same format, to pass over to #browseMessageList:name:.

It causes a barf in MessageSet class>>#parse:toClassAndSelector: for a rather amusing reason; note how the line in the middle tries to parse the incoming list

tuple := (codeReferenceOrString asString includesSubstring: '>>')
				ifTrue: [(codeReferenceOrString findTokens: '>>') fold: [:a :b| (a findTokens: ' '), {b first = $# ifTrue: [b allButFirst] ifFalse: [b]}]]
				ifFalse: [codeReferenceOrString asString findTokens: ' .'].

That check for '>>', the separator we so often use within a method reference? Guess what happens when we try to handle the input line 'ThirtyTwoBitRegister >> calls: >=' :-) I guess it is simply a fluke that no method with a > in the name is currently mentioned in #allUnimplementedCalls!

The #findTokens: simply isn't doing what I think the author expected. Trying to parse the list of strings we get from #allUnimplementedCalls et al. needs more thought, and perhaps the list *created* needs more thought too. 

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- On permanent leave of absence from his senses.