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