Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Jeff Higgins <jeff@invalid.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Help with Deck of cards assignment and getting it to deal...
Date: Sun, 03 Aug 2014 17:19:17 -0400
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <lrm90o$aem$1@dont-email.me>
References: <lrhe0d$l3n$1@dont-email.me> <lrlj8k$6fc$1@dont-email.me> <lrll78$jtc$1@dont-email.me> <lrlra4$1tn$1@dont-email.me> <lrm0rl$c1f$1@dont-email.me> <53de8cd5$0$299$14726298@news.sunsite.dk> <lrm78o$t48$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 3 Aug 2014 21:19:21 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="b896cb427f8c4d19d14880347aa9d6ce"; logging-data="10710"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rcFTMI+yGihc4OTbheo1MeGobFQgd06A="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.6.0
In-Reply-To: <lrm78o$t48$1@dont-email.me>
Cancel-Lock: sha1:MIP7UofmnKgyPESqfudXG+aKO78=
Xref: csiph.com comp.lang.java.programmer:29542

On 08/03/2014 04:49 PM, Eric Sosman wrote:
> On 8/3/2014 3:26 PM, Arne Vajhøj wrote:
>> [...]
>> I must admit that I can not follow you.
>>
>> The fact that different games may use a different ordering is
>> not an argument against Comparable<>.
>>
>> Comparable<> is not the one and only ordering. Comparable<> is
>> just the natural ordering. It is perfectly valid to have a
>> Comparable<> with the natural ordering and a bunch of
>> Comparator<> to handle the context specific orderings.
>
>      Although one could select different Comparators for different
> games -- one for Ace-low, say, and another for Ace-high -- there
> is no way a Comparator could work for "Ace-either" games like Poker
> (and certainly not for "Ace-both" games like high-low Poker!).  Like
> Comparable, Comparator reflects a _total ordering_ on the objects it
> compares, and a total ordering must be transitive:
>
>      If X < Y and Y < Z then X < Z, for all X,Y,Z.
>
> In Poker, one can have
>
>      Ace < Five and Five < Ten but Ten < Ace
>
> ... violating transitivity, so the ranks do not follow a total order.

In my proposed interface Ace is a valid Rank but Five and Five is not.
In my proposed interface I cannot see where any contract is broken by
run time variation of the natural ordering of the Rank. Sure, comparing
one Rank object at different times or places and getting different
results might seem odd but not wrong. I may be though. Please correct
me if this is the case.

>      One could, of course, implement a Comparator (or a Comparable)
> that broke the rules and violated its "contractual obligation" to
> impose a total order.  But a Comparable/Comparator that didn't behave
> as it should would make mockery of the claim
>
>  > Your Card class will be more easily used if it implement the
>  > java.lang.Comparable<T> interface
>
> ... because none of the Comparable- or Comparator-based utility
> classes and methods would behave properly: Collections.sort(),
> Arrays.binarySearch(), SortedMap(), ...  Something that simply
> doesn't work cannot be "more easily used."
>