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"

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

> 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.

> And finally "Because in almost every programming language..." is not an
> argument.
> You could argue that "1 + 2 * 3" should return "7", because that's how
> every language does it and that's how mathematicians did it for
> thousands of years. And yet Smalltalk happily returns "9" and yet it
> makes sense, and some could argue that it's even better.
>
> Peter
>
> On Sun, Aug 2, 2015 at 4:59 PM, Alexandre Bergel <[hidden email]
> </user/SendEmail.jtp?type=node&node=4840722&i=0>> wrote:
>
>     > I'd say it is questonable if SequenceableCollections should be comparable by default.
>
>     +1
>
>     Alexandre
>     --
>     _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>     Alexandre Bergel http://www.bergel.eu
>     ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p4840722.html
>
> To unsubscribe from Comparison for SequencableCollection, click here
> <
> NAML
> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

View this message in context: Re: Comparison for SequencableCollection
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.