0006920: Method Finder: put matches starting with search token at the top

(0011774 - 1194 - 1492 - 1492 - 1492 - 1492 - 1492)
wiz
02-14-08 02:52

Hi Ken,

I was looking thru yesterdays irc log and saw your sortblock logic problem.
  sorted sortBlock: [:x :y |
                                        (x startsWith: aString)
                                                ifTrue: [(y startsWith: aString)
                                                        ifTrue: [ x asLowercase <= y asLowercase]
                                                        ifFalse: [ true ]]
                                                ifFalse: [(y startsWith: aString)
                                                                        ifTrue: [ false ]
                                                                        ifFalse: [x asLowercase <= y asLowercase]]].
Is there a cleaner way to implement that sortBlock?

The logic reduces to:

[ :x :y |
    (x startsWith: aString) == (y startsWith: aString)
        ifTrue: [ x asLowercase <= y asLowercase ]
        ifFalse: [ x startsWith: aString ] ]

in English

If they have the same prefix sort order wins.
If they are different then which ever of them has the prefix wins.

Hth.

I did a lot of logic puzzles as a kid.

Yours in curiosity and service, --Jerome Peace

(0011789 - 267 - 267 - 267 - 267 - 267 - 267)
KenCausey
02-14-08 19:54

Wow, amazing. I have to say that at first I was skeptical but after some testing I confirmed that it worked and then I started puzzling through the logic and I believe that is a significant improvement. Thank you! Would you like to attach a new version or shall I?

(0011800 - 438 - 438 - 438 - 438 - 438 - 438)
KenCausey
02-14-08 22:52

Oh, and I ask, not because I'm lazy (well, OK I am lazy so that's a reason, just not the main one) but because since the only change is the sorting method, I think you should get the credit for the better sorting logic by having your initials associated with the new version. Of course, having this incorporated in a released image in its current form is probably unrealistic, I guess this really needs to be a preference. But whatever.

(0011808 - 454 - 520 - 520 - 520 - 520 - 520)
wiz
02-15-08 07:53

Hi ken,

Less work for me if you take the credit and do the driving.

The logic for the change (as I mentioned in my email) turns out to be the pattern for primary and secondary sorts.

If and only if the primary sort is the same sort by the secondary key.
Else sort by the primary key (x has the prefix when y does not).

Your code did exactly the same thing with a wider logic tree.

It was a nice exercise and glad I could help. Cheers -Jer

(0011809 - 455 - 515 - 515 - 515 - 515 - 515)
wiz
02-15-08 08:02

A second thought on preferences.

I think this would stand as a reasonalbe fix/enhancement that people could live with.

If you hedge bets with a preference you are actually making things harder to maintain. Each preference would double the number of tests a careful tester would run.

And the rippers (pavel in particular) will be tempted to revert the change just to remove the preference.

Hth.

Yours in curiosity and service, --Jerome Peace

(0011810 - 62 - 62 - 62 - 62 - 62 - 62)
KenCausey
02-15-08 21:40

Please see the second version for sort logic ala Jerome Peace.

Issue History
Date Modified	Username	Field	Change
02-13-08 19:12	KenCausey	New Issue
02-13-08 19:12	KenCausey	File Added: SelectorBrowserLeadingAtTop-klc.1.cs.gz
02-14-08 02:52	wiz	Note Added: 0011774
02-14-08 19:54	KenCausey	Note Added: 0011789
02-14-08 22:52	KenCausey	Note Added: 0011800
02-15-08 07:53	wiz	Note Added: 0011808
02-15-08 08:02	wiz	Note Added: 0011809
02-15-08 21:39	KenCausey	File Added: SelectorBrowserLeadingAtTop-klc.2.cs.gz
02-15-08 21:40	KenCausey	Note Added: 0011810
07-04-08 01:22	matthewf	Relationship added	child of 0007110

Notes
(0011774 - 1194 - 1492 - 1492 - 1492 - 1492 - 1492) wiz 02-14-08 02:52	Hi Ken, I was looking thru yesterdays irc log and saw your sortblock logic problem. sorted sortBlock: [:x :y \| (x startsWith: aString) ifTrue: [(y startsWith: aString) ifTrue: [ x asLowercase <= y asLowercase] ifFalse: [ true ]] ifFalse: [(y startsWith: aString) ifTrue: [ false ] ifFalse: [x asLowercase <= y asLowercase]]]. Is there a cleaner way to implement that sortBlock? The logic reduces to: [ :x :y \| (x startsWith: aString) == (y startsWith: aString) ifTrue: [ x asLowercase <= y asLowercase ] ifFalse: [ x startsWith: aString ] ] in English If they have the same prefix sort order wins. If they are different then which ever of them has the prefix wins. Hth. I did a lot of logic puzzles as a kid. Yours in curiosity and service, --Jerome Peace

(0011789 - 267 - 267 - 267 - 267 - 267 - 267) KenCausey 02-14-08 19:54	Wow, amazing. I have to say that at first I was skeptical but after some testing I confirmed that it worked and then I started puzzling through the logic and I believe that is a significant improvement. Thank you! Would you like to attach a new version or shall I?

(0011800 - 438 - 438 - 438 - 438 - 438 - 438) KenCausey 02-14-08 22:52	Oh, and I ask, not because I'm lazy (well, OK I am lazy so that's a reason, just not the main one) but because since the only change is the sorting method, I think you should get the credit for the better sorting logic by having your initials associated with the new version. Of course, having this incorporated in a released image in its current form is probably unrealistic, I guess this really needs to be a preference. But whatever.

(0011808 - 454 - 520 - 520 - 520 - 520 - 520) wiz 02-15-08 07:53	Hi ken, Less work for me if you take the credit and do the driving. The logic for the change (as I mentioned in my email) turns out to be the pattern for primary and secondary sorts. If and only if the primary sort is the same sort by the secondary key. Else sort by the primary key (x has the prefix when y does not). Your code did exactly the same thing with a wider logic tree. It was a nice exercise and glad I could help. Cheers -Jer

(0011809 - 455 - 515 - 515 - 515 - 515 - 515) wiz 02-15-08 08:02	A second thought on preferences. I think this would stand as a reasonalbe fix/enhancement that people could live with. If you hedge bets with a preference you are actually making things harder to maintain. Each preference would double the number of tests a careful tester would run. And the rippers (pavel in particular) will be tempted to revert the change just to remove the preference. Hth. Yours in curiosity and service, --Jerome Peace

(0011810 - 62 - 62 - 62 - 62 - 62 - 62) KenCausey 02-15-08 21:40	Please see the second version for sort logic ala Jerome Peace.