On Sun, Aug 2, 2015 at 6:44 PM, webwarrior <r...@webwarrior.ws> 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?
