Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Help with Deck of cards assignment and getting it to deal... Date: Sun, 03 Aug 2014 16:49:27 -0400 Organization: A noiseless patient Spider Lines: 42 Message-ID: References: <53de8cd5$0$299$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 3 Aug 2014 20:49:28 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="29832"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19h6fPV2HP8STddODfmUTVI" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <53de8cd5$0$299$14726298@news.sunsite.dk> Cancel-Lock: sha1:h4EKBI5vKTHx5BR0Ihi23mjnCVI= Xref: csiph.com comp.lang.java.programmer:29538 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. 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 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." -- esosman@comcast-dot-net.invalid