Smalltalk - Re: Comparison for SequencableCollection

Smalltalk › Pharo › Pharo Smalltalk Users

Re: Comparison for SequencableCollection

Posted by Peter Uhnak on Aug 02, 2015; 5:23pm
URL: https://forum.world.st/Comparison-for-SequencableCollection-tp4840704p4840724.html

On Sun, Aug 2, 2015 at 6:44 PM, webwarrior <[hidden email]> wrote:

On 02.08.2015 19:02, Peter Uhnák [via Smalltalk] wrote:

> (a b c) = (b a c) if a = b
>
> (a b c) < (b a c) if a < b
> The semantics are well defined.
>
>
> Since you mentioned JavaScript, you should know that you can't compare
> arrays with ==, because it does object comparison.
>
> No. Sorted collection maintains order of its elements, and I'm talking
> about order on [the set of] sequencable collections
>
> This will make sense only if the objects have overriden their #=.
> Which also means that it is not very useful to use #<, because you can't
> define order without overriding #=.
Technically, you can:
(a < b) not and: [ (b < a) not ] "a and b are equal"

Well if the two objects are not comparable, then you've just made them equal. :)

But of course it's reasonable to implement #= and #hash along with #< -
that's what TComparable requires.

Implementing #=/#hash just to achieve ordering seems like a terrible idea, considering #= affects a lot and often it will be context-dependent. (Sometimes you want to compare objects one way, sometimes another, that's why there's #sorted: method.)

> Compare it to sorting a collection, where you can either do #sorted,
> which will do "a <= b" by default, but you can still do #sorted: and
> specify the sort order, dtto with PluggableDictionary etc.
> So if anything, it would make more sense to be able to block-based
> testing (without relying on #<), because more often then not you will
> have your values wrapped in some (bigger) objects.

Something like #compare:using: where second argument is a binary block?
Might be a solution, although not as elegant.
Question is what are return values of the method and what is expected to
be returned from the block?
String>>#compare: returns integer from 1 to 3;
SequencableCollection>>#findBinary: expects either 0, negative or
positive integer; #sorted: expects boolean; #max:, #min:, etc. expect
object to be compared.

My point was, that in object world you will usually have more complex objects than just strings.

For example you have a class "Person" that has "name" and "surname" attributes.

Suddenly you can't override #=, because it doesn't make sense in context to lexicographic ordering...

do you want the order to be by name or by surname? Or something else?

That's why I wrote that implementing just #< has very constrained use-case, because you can't specify what you want to order.

Of course you can do "somePeople collect: #name < (otherPeople collect: #name)" but you still want it to be done on People collection, not the collection of strings.

Or maybe I am forcing not very common use case?